Chris,
i=0 -- copy mapImage (in sysmem) to dummyImage (in VRAM)
i=1 -- a) copy mapImage (in sysmem) to cached texture version of
mapImage (in VRAM)
b) copy mapImage (texture in VRAM) to dummyImage (in VRAM)
later -- copy mapImage (texture in VRAM) to your Swing backbuffer
(in VRAM)
Thanks for
Jim/Chris,
On using VolatileImages. While I am happy that I would have to manage the
overheads most of my images are translucent, and the target audience of my app
often has older machines. Often the d3d pipeline performs much better than
opengl.
Regards,
Alistair
[Message sent by forum
A quick note.
I am working on a 360 panorama viewer. I'll describe briefly my architecture.
I load images using my own file loader class from a separate thread spawned
from the init() method of my applet. I download the image file as bytes in an
ordinary file transfer. Once I have the
Thanks for all of the advice. You provided enough hints for me to get a
workaround that performs just as well on both the opengl and d3d pipelines.
This is what works for me:
In a static method do something like this so I have a dummy graphics lying
about for future use:
GraphicsEnvironment
[EMAIL PROTECTED] wrote:
Thanks for all of the advice. You provided enough hints for me to get a
workaround that performs just as well on both the opengl and d3d pipelines.
This is what works for me:
In a static method do something like this so I have a dummy graphics lying
about for future
As I asked in one of my previous email, what do you think about
using acceleration priority property for this? Say, if it's
1.0 then we try to cache the image on first try. 0.0 currently means that
we won't attempt to
accelerate it and release the cached version.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
As I asked in one of my previous email, what do you think about
using acceleration priority property for this? Say, if it's
1.0 then we try to cache the image on first try. 0.0 currently means that we
won't attempt to
accelerate it and release the cached version.
On May 22, 2007, at 2:50 AM, [EMAIL PROTECTED] wrote:
Thanks for all of the advice. You provided enough hints for me to
get a workaround that performs just as well on both the opengl and
d3d pipelines. This is what works for me:
In a static method do something like this so I have a dummy
As I asked in one of my previous email, what do
you think about
using acceleration priority property for this?
Say, if it's
1.0 then we try to cache the image on first try.
0.0 currently means that we won't attempt to
accelerate it and release
the cached version.
Sounds good to me
It would be nice to get a method in Image that allows me to 'make this Image
object managed if possible' without this workaround.
If you want more explicit control over acceleration then the best route
would be to create your own VolatileImage objects and manage them
yourself. That is
That's a good point, and it's an approach that I often recommend
because of the nice heap savings, as long as you're willing to live
with increased code complexity as Jim suggests. However, it's worth
mentioning some subtle differences between our (current)
implementations of managed images and
This is surprising, it should behave exactly the
same for
both pipelines.
That is what I thought. Unfortunately it is not the case. I have tried the
strategy of rendering to a 'dummy' VolatileImage. Using the opengl pipeline it
takes 2 drawImage calls before isAccelerated returns true.
That is what I thought. Unfortunately it is not the case. I have tried the
strategy of rendering to a 'dummy' VolatileImage. Using the opengl pipeline
it takes 2 drawImage calls before isAccelerated returns true. Using the d3d
pipeline I can not get isAccelerated to return true by rendering
Managed images only become managed after a certain number of render from
operations, such as a call to drawImage(). The threshold is adjustable using
the Sun specific flag:
p
-Dsun.java2d.accthreshold=x where x is the number of render operations before
that image will be cached in VRAM. Setting
Another way besides adjusting the acceleration threshold
via the property is to prime the images before rendering as
you're loading them.
It could be done by rendering an image to a VolatileImage until
the former becomes accelerated as reported by Image.getCapabilities()
(or until a
Thanks Fred. Great information.
I tried -Dsun.java2d.accthreshold=0 as you described. It works fine when I have
enabled the opengl pipeline using -Dsun.java2d.opengl=true, however if I have
the d3d pipeline enabled with -Dsun.java2d.d3d=true then I seem to loose
acceleration for all loaded
[EMAIL PROTECTED] wrote:
Thanks Fred. Great information.
I tried -Dsun.java2d.accthreshold=0 as you described. It works fine when I have
enabled the opengl pipeline using -Dsun.java2d.opengl=true, however if I have
the d3d pipeline enabled with -Dsun.java2d.d3d=true then I seem to loose
Thanks Javadesktop -- whomever you are...
Good set of references.
Some questions:
I wrote an applet to display panoramic images. To display them properly, there
is a necessary projection to make images look right. I won't go into the
details of the projection but that projection is not in
I am having problems getting the performance I want when drawing images.
I load a BufferedImage using ImageIO then draw it to a JPanel using the
Graphics2D.draw(Image, AffineTransform, ImageObserver) method. The first time I
draw this image it is much slower than subsequent calls. I think that
19 matches
Mail list logo
