> On Apr 3, 2015, at 15:18, Sergey Bylokhov wrote:
>
> 02.04.15 12:19, Hendrik Schreiber wrote:
>> Sergey, do I understand this correctly, when I say, it seems that using the
>> "wrong" image type there is a two time penalty, but once the image is cached
>> (which happens, once we drew it), it
02.04.15 12:19, Hendrik Schreiber wrote:
Sergey, do I understand this correctly, when I say, it seems that
using the "wrong" image type there is a two time penalty, but once the
image is cached (which happens, once we drew it), it will draw as
quickly as any other VRAM-cached image? In other wo
> On Apr 1, 2015, at 16:32, Sergey Bylokhov wrote:
>
> 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
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 w
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 so
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
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, Hendri
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
On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
If my understanding of the current drawing pipeline is correct, RGBA without
premultiplication is slow as premultiplication is done on-the-fly when
drawing—at least for OS X and OpenGL, as pointed out in
https://bugs.openjdk.java.net/browse/JDK-8059
Hi Hendrik,
You also need to look at the texture caching that goes on. Decoders
bring the image into a RAM representation and that can sometimes be used
directly and so it's format might matter, but we typically upload image
data into textures in VRAM and it is that format which is critical f
> On Mar 26, 2015, at 22:52, Jim Graham wrote:
> On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
>> Nevertheless, I wouldn't mind some feedback regarding converting
>> ToolKitImages easily to something that can be drawn faster
>> (TYPE_INT_ARGB_PRE). Don't we all want that?
>> Or asked the other w
On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages
easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all
want that?
Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be
> On Mar 26, 2015, at 16:32, Alexander Scherbatiy
> wrote:
>
> On 3/26/2015 3:49 PM, Hendrik Schreiber wrote:
[...]
>>
>> Therefore, in the spirit of
>> https://bugs.openjdk.java.net/browse/JDK-8059943, I'd like to suggest, to
>> either move sun.awt.image.MultiResolutionImage to some java.*
On 3/26/2015 3:49 PM, Hendrik Schreiber wrote:
Hey there,
I'm in the process of moving some custom code to take advantage of the fairly
new MultiResolutionImage capabilities.
Loading multi resolution stuff works nicely, but I fear drawing is a bit of a
problem.
In my old mechanism, I would
-
Hey there,
I'm in the process of moving some custom code to take advantage of the fairly
new MultiResolutionImage capabilities.
Loading multi resolution stuff works nicely, but I fear drawing is a bit of a
problem.
In my old mechanism, I would
- load images using the toolkit
- create a screen-
15 matches
Mail list logo
