On Mon, 27 Jan 2020 15:30:27 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> I would be very cautious of using multi-threading here. In any case, I think >> that the issues around absolute performance could be handled separately. >> >> Having said that, given my review comments, along with the concerns over >> performance regressions for those cases that will now be tiled, but formerly >> weren't, I no longer think this is a good candidate for openjfx14. This PR >> should be retargeted to the `master` branch for openjfx15. > > I thought of one possibility that might be worth looking into for a short > term fix (i.e., could still go into openjfx14). Rather than relying on > `PrismSettings.maxTextureSize` you could instead try to render the entire > image (as is done today) in a try / catch block, and only fall back to tiling > if there is an exception. That way there would be no concern over any > possible performance regression, since the only time we would use tiling > would be in the case where it fials today. > > What do you think? I have tested using a recipient WritableImage with an IntARGB pixel format (so that is aligned with that of the tile), that I construct by supplying a PixelBuffer, and as expected that performance of the tiled code is much more in line with that of the non-tiled version. One overhead left is the allocation of the extra buffer, but it is far less significant. The problem with this approach is that the "best" pixel format (as in similar to that of RRT) isn't the same depending on the rendering pipeline (e.g. d3d is intARGB while es2 is byteBGRA) so that would require adding a fair amount of code to determine the best possible scenario depending on all the constraints (keeping in mind the caller can also provide its own WritableImage...) that in turn would need thorough testing. All in all, I agree the risk of regression is probably too great for this to make it into openjfx14 with so little time left. Instead, I will prototype Kevin's proposal to only use tiling when it would fail with the current code and use what I've learned here to propose a more robust fix targeted at openjfx15 ------------- PR: https://git.openjdk.java.net/jfx/pull/68
