JDK-8092325 : Make path masks super-shader capable or multi-threaded capable
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-08-09
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8098094 - Super Shader
Description
Many paths may be small and easily packed into a texture atlas to aid in super shading. Maybe this could be shared with the region image cache. However to make this really work, we probably need to change the way we handle texture masks for paths. For example, if I have a line which traverses the screen from bottom left to top right, at the moment what we do (if I understand correctly) is create a mask the size of the quad that would represent that line, which would be equal in size to the size of the screen. Instead, we could break the line down into, say, 128x128 chunks such that each mask would contain approx. 181 linear pixels of the line. If we were really clever we could special case this situation so that we reused the same mask for each portion of the line (except maybe the first & last segments where we might encounter end caps we have to deal with or whatnot).

The main benefit of this approach is that by breaking down the stroked path into common block sizes that are reasonably sized, we can easily pack them densely into a texture atlas, and if it happened to be part of the same atlas used for region images we can use the super shader. In addition, we reduce the overall number of pixels we need to upload to the card. Also, by breaking it up into smallish tiles, we could possibly do multi-threaded rasterization of each particular chunk of the stroke, and multi-threaded texture uploads (if it turned out that this helped).
Comments
A couple other thoughts. One idea is that instead of breaking things down into 128x128 blocks, we instead do it based on the run length of a path. SO for example, we use a stroke iterator to walk along the stroke and collect 128 pixels of run length. However high / wide the corresponding texture / quad should be is determined by analyzing the run. For example, if I had a single 512px horizontal line I would collect 4 5px (plus whatever vertical padding for the AA) x 128px wide textures to send to the card. (Of course the example is bad because you could maybe reuse some of those textures but anyway, you get the idea). So that if the slope of the line is 45 deg then you end up with the worst case (a square block) but if the slope is less, then fewer pixels are accumulated and processed. Another thought is that obviously this breaks down when you have a curve looping back on itself. For example, if I had a ball of yarn made of 20,000 loops of thread, and it all fit into 128x128 block, then I'd rather just send that block rather than a different block for each 128 pixels of run length.
09-08-2013
Has anyone measured the total amount of mask data used in a given scene? Region backgrounds pack nicely because they can have their "middle parts" compressed out, but masked shapes don't have any such obviously redundant areas. Also, the example talks about a line which uses a fairly standard "rectangle farm" texture as its source, so that is already super-shader compatible...
09-08-2013
Actually I doubt it is possible to do multi-threaded texture uploads to the same atlas, so if we found that multithreaded texture uploads for paths was better than super-shader (because more time is spent uploading textures than switching contexts) then we'd opt to store the path textures individually, whereas if we found that super shader was a bigger win we'd bail on multi-threaded texture uploads. In either case, this is trading smaller texture data (both for upload and for fragment shader rendering) for increased geometry data. But since at the moment we're nowhere near the limits of geometry supported on even mobile GPUs, but we are getting hammered on bandwidth & fragment shader limits, this is probably a good tradeoff.
09-08-2013