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.
