[Rev 03] RFR: 8088198: Exception thrown from snapshot if dimensions are larger than max texture size

Frederic Thevenet github.com+7450507+fthevenet at openjdk.java.net
Tue Jan 28 18:03:50 UTC 2020

On Mon, 27 Jan 2020 18:45:17 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> 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

I've made the change suggested by Kevin, and it works as expected. 
It is not very elegant but it does provide relief with regard to the core issue while avoiding risks of performance regressions.

Now with regard to a follow-up PR targeted at the next release, I assume a new issue needs first be filed into the JBS first; should I just file a new bug via https://bugreport.java.com/bugreport (I don't have access to https://bugs.openjdk.java.net)?


PR: https://git.openjdk.java.net/jfx/pull/68

More information about the openjfx-dev mailing list