On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
If my understanding of the current drawing pipeline is correct, RGBA without
premultiplication is slow as premultiplication is done on-the-fly when
drawing—at least for OS X and OpenGL, as pointed out in
https://bugs.openjdk.java.net/browse/JDK-8059943
That's an odd bug. I'll note that it points out that we had missing
loops in the OpenGL pipeline to directly deal with the non-PRE data and
it links to a bug that adds those loops for more direct handling. It's
also not clear why those BufferedImage objects weren't cached. If you
create a BI and render to it and then blit from it a bunch of times it
should be cached in VRAM and the format shouldn't matter, but if you are
constantly rendering to the BI, then our cache never has time to set up
- and if you grab the data buffer for that BI, then it will never be
cached. But the buffers we use in the ImageRepresentations should be
static and should be cached.
I'm not saying that I have all of the answers as to whether or not
changing the PNG decoder to use PRE buffers would help, I'm just trying
to delineate all of the considerations that affect whether this is a
practical issue or not. We'd need test cases to test if any of the
mechanisms I'm describing are doing their job or not...
...jim
