On Tue, 28 Jan 2020 16:00:35 GMT, Frederic Thevenet <github.com+7450507+ftheve...@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. ------------- PR: https://git.openjdk.java.net/jfx/pull/68
