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
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
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
[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
10 matches
Mail list logo
