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

[Sergey Bylokhov]

Hi, Jim.
31.03.15 0:00, Jim Graham wrote:
> Hi Sergey,
>
> Slow us down where?
Slowdown occurs before the images will be cached in the native texture. 
At least two times: for the first time "image->conversion->window" blit 
and for the second time "image->conversion->texture->window" blit. Plus 
we will get a slow down when we cannot create a texture for some 
reason(big/unsupported size, low vc memory on intel etc).
Simple image copy on my osx 10.10 retina(J2DBench 1000x1000 
BufferedImage to the screen):
argb_pre: num-reps="1268"
argb image: num-reps="539"
cached image: num-reps="10362"

Not a big deal, but based on this I changed all image types in the swing 
to eliminate these unnecessary conversions.

>
> Toolkit images should end up cached in textures loaded onto the video 
> card in a format that the GPU understands directly, aren't they?
>
> So, are you referring to slowing down in the upload to the texture 
> which happens only once for a toolkit image?  Or will it somehow cause 
> the resulting cached uploaded texture to underperform once it is 
> living on the GPU?  Or are there common operations on Toolkit images 
> where we do not use a cached texture?
>
>             ...jim
>
> On 3/30/15 12:28 PM, Sergey Bylokhov wrote:
>> 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.