Are you sure the images on Mac are still managed images?
We had similar performance problems, but it's because we were accessing
the underlying DataBuffer's to the bufferedimages.
Are you in any way "mucking" with the images? Or adding
ImageObserver's?
In our experience Mac is always slower than Windows when it comes to
images... but there is a point at which we called it "abysmal"... and
there are ways to avoid the abysmal state. :)
On Nov 2, 2005, at 1:37 AM, Jerry wrote:
Hi,
I know this has been the subject of much heated discussion in the
past, but not for some time, so....
I have a situation where I have two BufferedImages and in a loop I
draw image A into image B twice, then swap A and B over to get a
feedback effect. On my Mac this goes a factor of ten slower than on a
slower PC, making the Mac version unusable. Investigation shows that
with 256x256 images, the first drawImage of each loop takes on the
order of half a second whereas the second one takes a few
microseconds. On Windows, both are equally fast. It's actually faster
on the Mac to not call drawImage and do my own affine transform and
alpha compositing in pure Java. If I could get Shark to work (but
that's another story), I suspect it would tell me that the time is
spent shuffling images to and from the GPU.
Does anyone have any insight into this? Is there any way to turn off
this business of keeping mirrors of BufferedImages in VRAM, and would
that help? In my case, these images will never be drawn to the screen,
if that's any help. The mirroring also seems to be bug-ridden, e.g. if
you call setRGB to change the pixels of an image, these changes often
get wiped out by the next graphics operation you do.
Jerry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
