Why are primitive operations slower on OGL?

[Hopper]

Hi there!

I noticet that OGL accerlation speeds up expensive accerlation a lot, but simple operations like drawLine, fill… are slower according to Java2Demo.
It seems especially operations relying OGLFillSpans are slower than on X or GDI.

I tested against: GF460mx, GF5200

cu Hopper

[campbell]

Which release are you using? JDK 5.0 or 6.0? We’ve made huge performance improvements, especially for simple primitives (with OGL enabled) in various Mustang builds. For example, in b27 we improved performance of all operations (e.g. drawLine 20-25x, fillRect 15-20x, drawImage 3-5x). And in build 39 (should be out today or Monday), I made another performance improvement that improves on those numbers by another 30-60%, depending on the operation. For more info, see here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6273431

I think you will find that we are now faster than X11 for many OGL operations in JDK 6.0. There are still some simple primitives that will be faster with X11, e.g. fillOval, because Xservers have optimized loops for those operations, where as we go through a fillSpans approach. Even simple fillRects can sometimes be faster with X11 because after all, they have a simple 2D implementation tuned for that sort of thing. OGL is both a 2D and 3D library, but it can’t always do as good a job at optimizing simple 2D operations like these (there’s a longer pipeline to go through).

We’re always looking at ways to improve performance, so this isn’t the final word on the story.

Thanks,
Chris

[Hopper]

@campbell

Which release are you using? JDK 5.0 or 6.0? We’ve made huge performance improvements, especially for simple primitives (with OGL enabled) in various Mustang builds. For example, in b27 we improved performance of all operations (e.g. drawLine 20-25x, fillRect 15-20x, drawImage 3-5x). And in build 39 (should be out today or Monday), I made another performance improvement that improves on those numbers by another 30-60%, depending on the operation. For more info, see here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6273431

Thanks for poiting this up - I was referring to mustang-b35.
I have seen great improvements since jdk-1.5, bigger apps like netbeans only even worked on mustang (seems most gl drivers are serious broken) and the netbeans-gui performs 25% faster running on OGL.

1.6 performs very well, especially in areas where i never thought it could - like Sw->Surface blits where it performs sometimes even better than the X11 implementation.

One drawback STR has: Context switching / Process Management overhead. On your dual-power systems you maybe don’t see it, but its there (althought its still a lot faster compared to 5.0). Nevermind since dual-cores are coming up, this will also make x-servers fly

I think you will find that we are now faster than X11 for many OGL operations in JDK 6.0. There are still some simple primitives that will be faster with X11, e.g. fillOval, because Xservers have optimized loops for those operations, where as we go through a fillSpans approach. Even simple fillRects can sometimes be faster with X11 because after all, they have a simple 2D implementation tuned for that sort of thing. OGL is both a 2D and 3D library, but it can’t always do as good a job at optimizing simple 2D operations like these (there’s a longer pipeline to go through).

Never thought this way - you are right. It must be lot harder for a driver to know howto optimize OGL commands compared to simple blit/drawLine/fillOval stuff 2d systems are optimized for.

We’re always looking at ways to improve performance, so this isn’t the final word on the story.

I am definitivly happy to hear that work on OGL will continue - I was a bit sad when I heard the D3D pipeline will be started, because I thought work on OGL will be stoppped. Great to hear this isn’t true!

A last thing which would interrest me: Are there any SwingMark results available showing how the different pipelines affect swing?

Thanks a lot, lg Hopper