[Rev 03] RFR: 8088198: Exception thrown from snapshot if dimensions are larger than max texture size
kcr at openjdk.java.net
Tue Jan 28 18:26:30 UTC 2020
On Tue, 28 Jan 2020 16:00:35 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:
>> 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)?
The change looks like what I would expect, so I'll finish my review in the next day or so. @arapte will need to re-review it as well.
Yes, we will need a new JBS bug ID for the follow-on.
More information about the openjfx-dev