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
Re-send: the list server bounced it a few days ago...
Chet.
Chet Haase wrote:
Hi Rick,
A good general approach is to copy any image into the image type
you'd actually like to use. For example, if you are going to
be using an image as a source for copies to the Swing window or
to other image
Re-send: the list bounced it a few days ago...
Chet.
Chet Haase wrote:
Eyal,
translate() adds the given translation to the one that exists
in the Graphics object already. So the new x,y are relative to
the current translated origin, not the top left corner.
This doesn't affect objects you h
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
10 matches
Mail list logo