Skip to main content

Improved Java2D Pipeline?

10 replies [Last post]
pdoubleya
Offline
Joined: 2004-02-09
Points: 0

Hi

I just downloaded the latest snapshot

java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b28)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b28, mixed mode, sharing)

and have tried running our Flying Saucer with it (http://xhtmlrenderer.dev.java.net). I was interested in seeing if the enhancements to Java2D affect our performance.

For our tool, there is a slight regression in performance, 25-30%. The test loads a large XHTML file and renders it to an image without displaying it on-screen. We use Graphics2D directly, not Swing or other AWT classes for rendering (apart from images).

Am wondering if there are some flags that might affect performance? I had heard that the new single-threaded 2D pipeline should improve things.

I realize Mustang is probably compiled as a debug build, and am not expecting the moon--just want to know if there are some tuning options I am missing.

Thanks
Patrick

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
peterkessler
Offline
Joined: 2004-10-27
Points: 0

> Tiger: best load time for the page, scrolling is
> pretty smooth, but noticeable pauses (assume it's GC)
> when scrolling long document (hamlet page scrolling,
> Alice line scrolling)

If you run with -XX:+PrintGCDetails -XX:+PrintGCTimeStamps your stdout will have a log of when GC's happen and how long they take. (If scribbling on stdout is a problem, add -Xloggc:filename and the log will go to "filename".) You never know: those pauses might [b]not[/b] be GC.

Which collectors have you tried? If you want to try our "low-pause" collector, add -XX:+UseConcMarkSweepGC to the command line. You might see somewhat larger footprints (and need a slightly larger -Xmx), because it's not a compacting collector, but the pause times should be consistently shorter.

Thanks for trying Mustang!

pdoubleya
Offline
Joined: 2004-02-09
Points: 0

Dmitri

I just tried b27--it's within about 8% of the JDK 1.5.0_01 build. b28 as some regression.

I modified the test just slightly to skip the first five results (of 25), and here are the average processing times:
Tiger: 193ms
b27: 204ms
b28: 306ms

All of these reproduced pretty accurately on multiple runs.

I'm not set up for profiling this accurately at the moment. I mentioned the link to Java2D because when you run our "browser" and go to the larger pages, there is a noticeable lag on opening them and jerkiness in scrolling--so it can't be problems with, say, document parsing or styling.

Interesting, running the browser while I write this, some notes:
Tiger: best load time for the page, scrolling is pretty smooth, but noticeable pauses (assume it's GC) when scrolling long document (hamlet page scrolling, Alice line scrolling)

b27: page loading might be a smidgeon slower than Tiger, scrolling is OK but has some funny drawing issues--as I scroll there is a brief "flashing" effect at about 20% and 80% of the panel (e.g. the horizontal at that position); a little "jerky" in scrolling the long docs.

b28: very slow page loading, scrolling very slow and jerky.

Thanks for your help.
Patrick

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Patrick,

thanks for the info and the pointer to your benchmark.

We'll see what's up with the b27 vs 1.5.0 8% regression.

Do you see the regression with no opengl set?

Thanks,
Dmitri

pdoubleya
Offline
Joined: 2004-02-09
Points: 0

Dmitri

Performance is the same with b27 with or without OGL on.

I'll keep an eye on this on new Mustang builds.

Thanks
Patrick

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Hmm. The fact that you got the same results with and w/o ogl enabled probably means that the ogl pipeline is not enabled for some reason.

Could you run with -Dsun.java2d.opengl=True (with capital T), it'll print out a debug message saying if the pipeline is enabled.

Thanks,
Dmitri
Java2D Team

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Hi Patrick,

unfortunately there appears to be a vm performance regression in b28 so you may be hitting it.

You can try this: copy the jre/bin/client/jvm.dll file from b27 over the one in b28, and see if it makes any difference (backup the old dll first).

Also, it'd help if you mention your config (os, video card, drivers, and if you're using opengl or any other options).

Thanks,
Dmitri
Java2D Team

pdoubleya
Offline
Joined: 2004-02-09
Points: 0

Dmitri

Thanks for the response. I will download and try the b27 build.

Environment:
- Windows 2000 SP4
- HP Omnibook, P3M 1.133Gz
- 768M RAM
- Video: ATI Mobility M6
- resolution: running at 1280 x 1024, 60Hz notebook monitor
- hardware acceleration ON (on video card)

Only VM parameter I am setting is sun.java2D.opengl, have tried true and false. In this case, performance is slightly worse with true.

Many thanks (and sorry this ended up on the front page of java.net!)
Patrick

campbell
Offline
Joined: 2003-06-24
Points: 0

Hi Patrick,

> Only VM parameter I am setting is sun.java2D.opengl,
> have tried true and false. In this case, performance
> is slightly worse with true.

You mentioned that in this test, xhtmlrenderer will render into an offscreen image. Do you know how that image is created? Is it a VolatileImage?

Could you provide instructions on how to run this test? I'd like to give it a try to see if I can track down any performance problems related to the OGL pipeline.

Thanks,
Chris

pdoubleya
Offline
Joined: 2004-02-09
Points: 0

Hi Chris

Download the current xhtmlrenderer. From the command line, you can run
ant simple-page

This loads a single page and renders it to image 25 times. The average time is printed out at the end (and time elapsed as each run goes). The test class is org.xhtmlrenderer.test.SimplePageTest. You can try different pages--currently just by uncommenting lines. This is a smoke test to see if there are bad things happening.

As for the graphics rendering, the test uses org.xhtmlrenderer.simple.Graphics2DRenderer.renderToImage().
The relevant code is rendering to a BufferedImage. For testing purposes, we could use a VolatileImage--the purpose of renderToImage() is for someone to extract an image (at a specified size) of a given page, so VI would probably work OK (although I don't know at what points the VI could be lost, and if that would be an issue.

You can also run
ant browser

and try different pages from the Demos menu. Alice and Hamlet are two with slightly worse performance under Mustang build 28--I find the page takes longer to come up, and the scrolling is jerky.

Comments appreciated, thanks for offering to take a look.

Patrick

campbell
Offline
Joined: 2003-06-24
Points: 0

> As for the graphics rendering, the test uses
> org.xhtmlrenderer.simple.Graphics2DRenderer.renderToIm
> age().
> The relevant code is rendering to a BufferedImage.
> For testing purposes, we could use a
> VolatileImage--the purpose of renderToImage() is for
> someone to extract an image (at a specified size) of
> a given page, so VI would probably work OK (although
> I don't know at what points the VI could be lost, and
> if that would be an issue.
>

Thanks for the instructions. I'll try downloading the latest version next week when I'm in the office and will play around with it.

If xhtmlrenderer is rendering to a BufferedImage, then we'll be using our software loops (so performance should be the same regardless of whether OGL is enabled). You'd only get the benefit of OGL acceleration when rendering to the screen or to a VolatileImage...

As for the performance degradation in Mustang-b28, I'm almost certain this is caused by the VM regressions that Dmitri mentioned in b28. These should be resolved in an upcoming build.

Great to see that you're trying the latest Mustang bits though. The more eyes we have on these early snapshots, the better.

Thanks,
Chris