[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen compatible
From:       Jim Graham <james.graham () oracle ! com>
Date:       2015-03-30 21:00:08
Message-ID: 5519B958.5080607 () oracle ! com
[Download RAW message or body]

Hi Sergey,

Slow us down where?

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
>>>
>>>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]