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
Here is PlatformInfo's ouput on the machine with FAST display
Platform configuration:
CPU: Intel 32bit Single Processor
Operating System: Windows 98 (version 4.10 A (Build 2222))
DirectX version: DirectX 8.1 or greater
DirectX display devices: Device 0: Resolution (width x height x depth): 1152 x 864 x 16 Video memory (Total, Free): 13609 KB, 13609 KB Device driver 3dfx32v3.dll version 4.11.1.8154
GDI display devices: Primary: Name = \\.\Display1, Description = 3dfx Voodoo3
Here is PlatformInfo's ouput on the machine with SLOW display:
Platform configuration:
CPU: Intel 32bit Number of Processors: 2 Processor Speed: 997 MHz
Operating System: Windows 2000 (version 5.0 Service Pack 4 (Build 2195))
DirectX version: DirectX 7
DirectX display devices: Device 0: Resolution (width x height x depth): 1280 x 1024 x 32 Video memory (Total, Free): 27971 KB, 27971 KB
GDI display devices: Primary: Name = \\.\DISPLAY1, Description = Matrox Millennium G400 DualHead Max
is to forcibly disably our use of offscreen memory to see if that has any impact on your app's performance. You can do this by using the flag: -Dsun.java2d.ddoffscreen=false
This does greatly speed up rendering on the slow machine!
On the slow machine I updated DirectX to 9.x, but running without the flag produces the same results.
Running on Macintosh OS X is still slow (again, I know this is an issue for Apple). I tried creating an offscreen image directly: offImage_ = new BufferedImage(getWidth(),getHeight(), BufferedImage.TYPE_INT_ARGB_PRE); I tried a variety of type parameters to the BufferedImage constructor, and all exhibited the same slow rendering as before: offImage_ = Component.createImage(getWidth(), getHeight()); Is this "new BufferedImage()" being placed in VRAM? If so is there an API-guaranteed way to get around this? Such as creating a byte[] and passing that as rendering surface to the image?
Thanks, 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".
