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 image
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 membe
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)
Thank
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 V
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 essentia
> 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 goo
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
graphic
[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.
> 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,
>
[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 u
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 ge
> 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 render
> 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. U
Hi Ken,
Ken Warner wrote:
I think that making runtime parameters available programatically -- i.e.
from an applet or an app -- is very useful.
I think it is just irritating to have to "prime" or trick the VM into a
particular state.
Just let us set an acceleration flag an then deal with the c
Hi Dmitri,
I think that making runtime parameters available programatically -- i.e. from
an applet or an app -- is very useful.
I think it is just irritating to have to "prime" or trick the VM into a
particular state.
Just let us set an acceleration flag an then deal with the consequences...
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 t
[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
accel
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 imag
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
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:
-Dsun.java2d.accthreshold=x where x is the number of render operations before
that image will be cached in VRAM. Setting
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 t
21 matches
Mail list logo
