I noticed that some Swing applications I was using (e.g., JEdit) became unusably slow whenever my laptop (Dell XPS) was unplugged. I know that either/both the CPU and the graphics chip are probably scaled back on performance (and thus power consumption) when the laptop is unplugged, but not to the extent I was seeing in these Swing applications. I ran some tests (both 2D and native) to see what the problem was. It turns out the main bottleneck is text performance. This is seen through runs of J2DBench2 (where the drawString performance while unplugged was .55% (that's half of one percent, or 200x slower) the performance while plugged in), SwingMark (where the overall score was about 20x slower, and every test suffered similarly), and some micro benchmarks that I wrote. The main graphics operation in text rendering is Locking/Unlocking the destination surface; since we do not currently accelerate text operations, we render the text by locking the back buffer, copying the glyph pixels one-by-one, and unlocking the back buffer. So it seems reasonable that the core problem is the Lock/Unlock performance while unplugged. I wrote a native test (DDrawLockTest) to trace the root cause. My first attempts didn't find the problem; I was getting nearly the same performance for unplugged Lock/Unlock operations as I did while plugged in (occasional blips, but nothing on the order of what I saw with Java2D). Then I created the offscreen ddraw surface to be d3d-capable, which matches our approach in Java2D (the back buffer must be d3d-capable in order for us to be able to draw lines and textures to it). This finally showed the same results as I was seeing with Java2D; worse, in fact, because my native test hammered exclusively on Lock/Unlock. The performance I saw with DDrawLockTest was something like: 7 ms for 500 Lock/Unlock operations for the offscreen surface 18 ms for 500 Lock/Unlock operations for the onscreen primary surface while plugged in, but: 2600 ms for the offscreen 6100 ms for the onscreen primary when unplugged. Ignoring the onscreen primary surface performance (we actually don't do this in Java2D by default; locking the screen tends to cause flickering), we can see that the offscreen performance for this simple Lock/Unlock operation suffers by a factor of about 370x. I do not know if this is a widepread problem for Windows laptops , or whether it is specific to the XPS configuration (ATI 9700M), but this degree of performance loss for one of our core rendering approaches (using ddraw for the back buffer, locking that back buffer for common operations such as text) makes it unacceptable when the problem does occur. We should figure out how widespread the problem is and what it would take to fix the problem in general.
|