This could be more a difference in the graphics cards on these machines than the OSs and the CPU speeds. One of the huge bottlenecks that you can sometimes run into in rendering is doing any rendering to an VRAM-based image that requires read-back. In your case, at least the anti-aliasing primitives would require this because they are translucent (and thus are read-modify-write operations). Any other operations that you are performing that require reading would also bump into this problem.
It could be the case that your Windows98 machine cannot put the Swing back buffer in video memory (perhaps because it lacks enough VRAM). Swing would, therefore, put the buffer in system memory instead. Reads from this type of image would be _way_ faster than reads from VRAM, so you could be seeing better overall performance just because you are getting so much better performance just on those read operations.
We actually try to account for this type of behavior in VRAM images by providing a punting mechanism whereby we move the VRAM image into system memory when we detect a large proportion of read operations. But it could be that we are not detecting this case correctly for some reason and thus the buffer remains in VRAM (and the read operations remain slow).
This is all supposition based on your email. Perhaps there is something else going on here, but it is worth looking at your video setup on the machines and seeing if the stuff I'm talking about here applies to your situation.
Chet.
Tom Phelps wrote:
My application is a browser that renders a screen of mixed content: background filled rectangle of solid color, images, and text (sometimes antialiased). I render to an offscreen buffer returned by Component.createImage(int, int). On a 500MHz Pentium III this display very quickly. Scrolling always redraws the whole page, but even so scrolling by dragging the scrollbar is very fast, even on long pages.
However, this exact same Java same code on a Windows 2000 machine running dual 1GHz Pentiums and a flat panel display is *several times* slower. It can take a couple seconds to render the same screen (say, clipped to 640x480) that Windows 98 renders in a couple hundred milliseconds.
Running on Macintosh OS X produces the same results as on Windows 2000. I know this is Apple's domain, but it my be helpful to know that on OS X, Component.createImage(int,int) returns the following: [EMAIL PROTECTED]: type = 3 DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=ff000000 IntegerInterleavedRaster: width = 640 height = 700 #Bands = 4 xOff = 0 yOff = 0 dataOffset[0] 0
This happens with both Java 1.4.1 and 1.4.2 and probably all other versions of Java. Drawing with hardware-accelerated rendering is not an option because I sometimes need to retrieve part of the image that has been rendered and further massage it (e.g., with convolution filter), and apparently one cannot fetch data *from* the frame buffer. It appears that the slowness is due to the actual drawing on the offscreen image, not in drawing the offscreen image to the screen (Graphics.drawImage returns quickly, but this could be misleading as it might not block for the operation to complete). I tried creating a BufferedImage explicitly with many different types (TYPE_INT_RGB, TYPE_INT_ARGB, TYPE_INT_RGB_PRE, and others), but this did not affect rendering time.
My question is, why is drawing so much slower on much faster hardware with faster graphics cards? Is it a matter of optimized code not being available for the new graphics card (as to the flat panel)? Or of special-case loops not being available?
Tom
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
