[OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible

[Sergey Bylokhov]

28.03.15 4:10, Jim Graham wrote:
> 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?
It depends. Not the best format can slow down us from x2 to x10 and 
more(before we cache the image). On osx the best format is argb_pre, but 
it is unclear what is the best format on other platforms(especially on 
windows where we can switch loops gdi<-->d3d).
>
>             ...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
>>
>>


-- 
Best regards, Sergey.