On Monday, August 25, 2003, at 08:35 AM, Chet Haase wrote:
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".

Reply via email to