Skip to main content

[JAVA2D] TransAccel

3 replies [Last post]
Anonymous

Hello,

a simple question:

I tried to access the pixels directly through Raster->DataBufferInt but as
soon as I call:

DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer());

the image becomes non accelerated and there's apparently no way to
re-accelerate it.

I also noticed that setting the raster pixels with:

raster.setPixel(x,y,a,r,g,b);

works, but I suppose this solution gives very low performance.

so the question is: which is the bset way to change the pixels of an
accelerated (managed) image on the fly ?

Cheers,

Mik of ClassX
============================================================================
> ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) <
> Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it <
============================================================================

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Chet Haase

Hi Mik,

A simple question about a relatively complicated subject...

You have tripped upon the internal "rasterStolen" variable
that we use to detect when someone has accessed the
Raster/DataBuffer of a managed image.

We can accelerate managed images only when we know exactly
what is going on with the main copy of that image. That is,
if we can detect when that main copy changes, then we know
when to update our accelerated cache of that image. But the
API you are using to access the pixels (getDataBuffer())
defeats this approach because we can no longer detect
when the main copy has changed. That is, when you have
array access into the pixel data, we cannot easily detect
when you change values in the array, thus we cannot know
when the original copy has changed and our cached version
nees to be updated. So we punt.

There may be better ways for us to manage this internally
in the future, but for now we simply detect the case where
someone has gotten direct access to the pixel data and
turn off acceleration for that image.

The best ways to access the data in a managed image without
causing this punt are any methods that render to the image
without returning the data buffer. This includes the setPixel
methods in Raster and the setRGB methods in BufferedImage; both
of these change the data without giving you arbitrary access to
the data, so we can detect that the data has changed and update
the cached/accelerated image appropriately. Another
approach is to render to a different image (perhaps a translucent
or transparent one) and then use drawImage() to copy the data
in. Finally, you can always use the standard rendering
primitives to tweak the data (drawLine(), fillRect, etc.).

None of these may be the fastest in the world for setting
pixel data, but at least they will allow you to set the data
without defeating acceleration.

The current state of hw accelerated images is that they
work well for static data, but are suboptimal for dynamic
data. This is just a result of the kinds of things we
needed to accelerated first in our long road toward full-on
hw acceleration of everything. The approach you use in your
app depends on the performance tradeoff between changing the
pixel data in the image versus copying those images to
some accelerated surface (e.g., the back buffer). For
some applications, it might work out better to have dynamic
sprites/images in software because our read/write access to
that data is much faster than when those images are stored
in VRAM. But if you are not changing those sprites/images
too frequently, then you will probably do better by
leaving them in VRAM so that they benefit from the
hw accelerated copy operations. As always, benchmark if
you need to know the Right Answer for your situation.

Chet.

Michele Puccini wrote:
> Hello,
>
> a simple question:
>
> I tried to access the pixels directly through Raster->DataBufferInt but as
> soon as I call:
>
> DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer());
>
> the image becomes non accelerated and there's apparently no way to
> re-accelerate it.
>
>
> I also noticed that setting the raster pixels with:
>
> raster.setPixel(x,y,a,r,g,b);
>
> works, but I suppose this solution gives very low performance.
>
> so the question is: which is the bset way to change the pixels of an
> accelerated (managed) image on the fly ?
>
> Cheers,
>
> Mik of ClassX
> ============================================================================
>
>>ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) <
>>Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it <
>
> ============================================================================
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Jonathan Shore

I was pondering the same question. I've noted that setting pixels via the
data buffer directly is 10x !!! faster than going through setRGB() on my
machine (I have a 2.4Ghz P4 with top of the line ATI graphics card
[windows]). I had thought that it was just code overhead in the layers or
would the differential between cache/DRAM vs VRAM be that significant?

If I am going to be writing pixels across a buffered image on, say, 1 in 5
renders does it ever make since to use setRGB() at 1/10th write perf? Is
there a good guide to the performance differences for accelerated and
unaccelerated operations?

Kind of feeling around in the dark with this stuff, would be good to know
more about what is going on underneath to make better rendering decisions
...

--
Jonathan Shore
Derive Inc

-----Original Message-----
From: Discussion list for Java 2D API [mailto:JAVA2D-INTEREST@JAVA.SUN.COM]
On Behalf Of Chet Haase
Sent: Friday, April 02, 2004 10:14 AM
To: JAVA2D-INTEREST@JAVA.SUN.COM
Subject: Re: [JAVA2D] TransAccel

Hi Mik,

A simple question about a relatively complicated subject...

You have tripped upon the internal "rasterStolen" variable
that we use to detect when someone has accessed the Raster/DataBuffer of a
managed image.

We can accelerate managed images only when we know exactly
what is going on with the main copy of that image. That is,
if we can detect when that main copy changes, then we know
when to update our accelerated cache of that image. But the API you are
using to access the pixels (getDataBuffer()) defeats this approach because
we can no longer detect when the main copy has changed. That is, when you
have array access into the pixel data, we cannot easily detect when you
change values in the array, thus we cannot know when the original copy has
changed and our cached version nees to be updated. So we punt.

There may be better ways for us to manage this internally
in the future, but for now we simply detect the case where someone has
gotten direct access to the pixel data and turn off acceleration for that
image.

The best ways to access the data in a managed image without causing this
punt are any methods that render to the image without returning the data
buffer. This includes the setPixel methods in Raster and the setRGB methods
in BufferedImage; both of these change the data without giving you arbitrary
access to the data, so we can detect that the data has changed and update
the cached/accelerated image appropriately. Another approach is to render
to a different image (perhaps a translucent or transparent one) and then use
drawImage() to copy the data in. Finally, you can always use the standard
rendering primitives to tweak the data (drawLine(), fillRect, etc.).

None of these may be the fastest in the world for setting
pixel data, but at least they will allow you to set the data without
defeating acceleration.

The current state of hw accelerated images is that they
work well for static data, but are suboptimal for dynamic
data. This is just a result of the kinds of things we
needed to accelerated first in our long road toward full-on
hw acceleration of everything. The approach you use in your app depends on
the performance tradeoff between changing the pixel data in the image versus
copying those images to some accelerated surface (e.g., the back buffer).
For some applications, it might work out better to have dynamic
sprites/images in software because our read/write access to that data is
much faster than when those images are stored in VRAM. But if you are not
changing those sprites/images too frequently, then you will probably do
better by leaving them in VRAM so that they benefit from the hw accelerated
copy operations. As always, benchmark if you need to know the Right Answer
for your situation.

Chet.

Michele Puccini wrote:
> Hello,
>
> a simple question:
>
> I tried to access the pixels directly through Raster->DataBufferInt
> but as soon as I call:
>
> DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer());
>
> the image becomes non accelerated and there's apparently no way to
> re-accelerate it.
>
>
> I also noticed that setting the raster pixels with:
>
> raster.setPixel(x,y,a,r,g,b);
>
> works, but I suppose this solution gives very low performance.
>
> so the question is: which is the bset way to change the pixels of an
> accelerated (managed) image on the fly ?
>
> Cheers,
>
> Mik of ClassX
> ======================================================================
> ======
>
>>ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) <
>>Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB:
>>http://www.classx.it <
>
> ======================================================================
> ======
>
> ======================================================================
> =====
> To unsubscribe, send email to listserv@java.sun.com and include in the
body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Michele Puccini

What we both probably miss is the possibility to write directly to
accelerated image data (gfx board memory).
Maybe I'm mistaking, but I guess there's something in the current java2d
implementation or maybe a combination of hardware/software reasons that
prevents the java2d staff to let us do this.
Maybe direct gfx memory allocation could solve this problem, but this
feature could be a bit out-of-scope for the current Java2D.

Mik
============================================================================
> ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) <
> Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB: http://www.classx.it <
============================================================================

----- Original Message -----
From: "Jonathan Shore"
To:
Sent: Saturday, April 03, 2004 3:34 AM
Subject: Re: [JAVA2D] TransAccel

I was pondering the same question. I've noted that setting pixels via the
data buffer directly is 10x !!! faster than going through setRGB() on my
machine (I have a 2.4Ghz P4 with top of the line ATI graphics card
[windows]). I had thought that it was just code overhead in the layers or
would the differential between cache/DRAM vs VRAM be that significant?

If I am going to be writing pixels across a buffered image on, say, 1 in 5
renders does it ever make since to use setRGB() at 1/10th write perf? Is
there a good guide to the performance differences for accelerated and
unaccelerated operations?

Kind of feeling around in the dark with this stuff, would be good to know
more about what is going on underneath to make better rendering decisions
...

--
Jonathan Shore
Derive Inc

-----Original Message-----
From: Discussion list for Java 2D API [mailto:JAVA2D-INTEREST@JAVA.SUN.COM]
On Behalf Of Chet Haase
Sent: Friday, April 02, 2004 10:14 AM
To: JAVA2D-INTEREST@JAVA.SUN.COM
Subject: Re: [JAVA2D] TransAccel

Hi Mik,

A simple question about a relatively complicated subject...

You have tripped upon the internal "rasterStolen" variable
that we use to detect when someone has accessed the Raster/DataBuffer of a
managed image.

We can accelerate managed images only when we know exactly
what is going on with the main copy of that image. That is,
if we can detect when that main copy changes, then we know
when to update our accelerated cache of that image. But the API you are
using to access the pixels (getDataBuffer()) defeats this approach because
we can no longer detect when the main copy has changed. That is, when you
have array access into the pixel data, we cannot easily detect when you
change values in the array, thus we cannot know when the original copy has
changed and our cached version nees to be updated. So we punt.

There may be better ways for us to manage this internally
in the future, but for now we simply detect the case where someone has
gotten direct access to the pixel data and turn off acceleration for that
image.

The best ways to access the data in a managed image without causing this
punt are any methods that render to the image without returning the data
buffer. This includes the setPixel methods in Raster and the setRGB methods
in BufferedImage; both of these change the data without giving you arbitrary
access to the data, so we can detect that the data has changed and update
the cached/accelerated image appropriately. Another approach is to render
to a different image (perhaps a translucent or transparent one) and then use
drawImage() to copy the data in. Finally, you can always use the standard
rendering primitives to tweak the data (drawLine(), fillRect, etc.).

None of these may be the fastest in the world for setting
pixel data, but at least they will allow you to set the data without
defeating acceleration.

The current state of hw accelerated images is that they
work well for static data, but are suboptimal for dynamic
data. This is just a result of the kinds of things we
needed to accelerated first in our long road toward full-on
hw acceleration of everything. The approach you use in your app depends on
the performance tradeoff between changing the pixel data in the image versus
copying those images to some accelerated surface (e.g., the back buffer).
For some applications, it might work out better to have dynamic
sprites/images in software because our read/write access to that data is
much faster than when those images are stored in VRAM. But if you are not
changing those sprites/images too frequently, then you will probably do
better by leaving them in VRAM so that they benefit from the hw accelerated
copy operations. As always, benchmark if you need to know the Right Answer
for your situation.

Chet.

Michele Puccini wrote:
> Hello,
>
> a simple question:
>
> I tried to access the pixels directly through Raster->DataBufferInt
> but as soon as I call:
>
> DataBufferInt dbi = (DataBufferInt)(wr.getDataBuffer());
>
> the image becomes non accelerated and there's apparently no way to
> re-accelerate it.
>
>
> I also noticed that setting the raster pixels with:
>
> raster.setPixel(x,y,a,r,g,b);
>
> works, but I suppose this solution gives very low performance.
>
> so the question is: which is the bset way to change the pixels of an
> accelerated (managed) image on the fly ?
>
> Cheers,
>
> Mik of ClassX
> ======================================================================
> ======
>
>>ClassX Development Italy Via Francesca, 463 I-56030 Montecalvoli (PI) <
>>Tel.(+39)-0587-749206 Fax.(+39)-0587-749206 WEB:
>>http://www.classx.it <
>
> ======================================================================
> ======
>
> ======================================================================
> =====
> To unsubscribe, send email to listserv@java.sun.com and include in the
body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".