[OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible
Jim Graham
james.graham at oracle.com
Sat Mar 28 01:10:31 UTC 2015
Thanks Sergey,
Have you been following the rest of this thread? Any thoughts on how
much the lack of PRE pixel format in the PNG loader might be hurting us?
...jim
On 3/27/15 5:31 PM, Sergey Bylokhov wrote:
> 28.03.15 0:50, Jim Graham wrote:
>> On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
>>
>> 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.
> Actually not, the second bug adds a loop which transform non-PRE surface
> to the PRE surface on the fly in software and scale it via OGL(before
> that, conversion and scale were done in software via transformhelper).
> In the JDK-8059943 we save one blit, which transform non_PRE BI to PRE.
> Plus it saves one more blit when we try to cache non_PRE BI into vram
> because this operation will be done via OGLGeneralBlit which also
> convert non-PRE to PRE on the fly.
>> 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
>
>
More information about the 2d-dev
mailing list