Skip to main content

Photomesa 2.0

4 replies [Last post]
selendic
Offline
Joined: 2006-02-17
Points: 0

Veeery nice application. And fast! And useful. However, does anyone from Sun can tell why from 1.4.1_02 it works very sluggish without -Dsun.java2d.ddoffscreen=false switch? 1.4.1_01 was last version that worked fine without it. A bug maybe?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chet
Offline
Joined: 2003-08-07
Points: 0

Sounds like a bug, possibly in our buffer-punting code. It's not surprising that it's smooth when ddoffscreen is disabled; this means we're using our software rendering routines for everything, so all zooming and copying is at the same speed of whatever we can do with the combination of the CPU and the bus speed down to the framebuffer. The jerkiness of the zooming with ddoffscreen enabled (default behavior) indicates that we are probably doing something like leaving the back buffer in video memory but we're being forced to do reads from it for the scaling operations; a very expensive operation that can cause performance hiccups.

I'll look into it...

Thanks,
Chet.

Anonymous

Well, there is some that that would effect the performance of the 1.4.1 VM. My guess would be a GDI leak is the problem that hurts performance. Check Bug #4766813.

http://developer.java.sun.com/developer/bugParade/bugs/4766813.html

chet
Offline
Joined: 2003-08-07
Points: 0

Apps like this can also be clobbered by the way that we cache the back buffer. Currently, the back buffer
lives in video memory by default (on Windows, at least). Depending on the operation you do to/from that buffer, we may end up punting that buffer into system memory instead.

One of the performance problems we have seen with this approach is that Managed Images (such as Swing icons or any image created with Component.createImage() or GraphicsConfiguration.createCompatibleImage()) do not necessarily know about the punt state of the back buffer. This means that they may end up doing a copy from their VRAM cached copy to the punted system-memory back buffer. This can be incredbily expensive, as it entails a read from VRAM.

Too much information, I'm sure. But the net result is that we realized this was a problem when we were getting the XP look and feel to work in jdk1.4.2 and fixed the problem (or at least most of the problems). Now, if the buffer gets punted, then the image copies to that buffer use system memory versions, and thus the copies are WAY faster than they were.

Check out jdk1.4.2-beta or later (I believe the full release ships sometime this month, but I don't know for sure). I think you'll find the problem is fixed. Or let us know if it's not...

Chet.
Java2D

selendic
Offline
Joined: 2006-02-17
Points: 0

Nope. I AM trying with 1.4.2-beta. Regression started with 1.4.1_02. I do suppose that photomesa guys are doing something funny in their code, becaouse they have "-Dsun.java2d.ddoffscreen=false" switch by default in their startup script. What worries me is that in pre 1.4.1_02 versions it is irrelevant if one uses that switch. 1.4.1_02 onwards (including 1.4.2-beta) has much jerkier zooming in and out of images and moving whole screen around when you remove switch from Photomesa.bat. All versions (1.4.x) are smooth with switch enabled. Try it for yourselves www.photomesa.com. XP, Matrox 550, Intel 1.5 Ghz. Java 1.4.2-beta client here.