|
Replies:
20
-
Last Post:
Dec 1, 2008 10:51 AM
by: Chris Campbell
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
Poor performance of Java2D
Posted:
Nov 24, 2008 8:19 PM
|
|
|
I am going to create application with some vector graphics. I like both Java and Qt. So in order to choose a particular one I decided to compare the performance of vector graphics rendering. There is a benchmark for Qt from Zack Rusin (http://zrusin.blogspot.com/2008/08/fast-graphics.html), so I have just rewritten it with Java2D with almost one-to-one correspondence. Here are my results of comparison: http://trac-hg.assembla.com/jgears/wiki
My question is the following: am I doing something wrong in Java2D and there is a way to improve performance in this simple benchmark?
I wonder if Java2D d3d pipeline is slower then Qt pure software rendering for this simple testcase. And what about Java2D OpenGL pipeline, is it enough to pass -Dsun.java2d.opengl=True to enable it?
|
|
|
|
|
|
|
Re: Poor performance of Java2D
Posted:
Nov 25, 2008 5:14 AM
in response to: kamre
|
|
|
jgears.jar does only contain class files but no code.
|
|
|
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 25, 2008 8:55 AM
in response to: kamre
|
|
|
FYI, jgears.jar appears to be broken - it's only 5.6K and is empty.
Dmitri
java2d@JAVADESKTOP.ORG wrote:
> Thaks for reply. I have updated jar file. In any way sources are available via http://trac-hg.assembla.com/jgears/browser or "hg clone http://hg.assembla.com/jgears".
> [Message sent by forum member 'kamre' (kamre)]
>
> http://forums.java.net/jive/thread.jspa?messageID=318666
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 25, 2008 9:50 AM
in response to: Dmitri Trembove...
|
|
|
Sorry, fixed now.
And several questions about the code.
1. Save/Restore of transformation in Graphics2D. Is this way:
AffineTransform saved = g2d.getTransform();
...
g2d.setTransform(saved);
efficient???
2. Fill/Draw functions. I often use fill and draw functions for the same path. Can this somehow be optimized? In Qt there is only one call to QPainter::drawPath and it simultaneously uses current pen for outline and current brush for filling.
3. I didn't find Path2D.arcTo and used Path2D.append(new Arc2D.Double(...), true). Is this intended way to add arc to path?
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 25, 2008 11:53 AM
in response to: kamre
|
|
|
Answers inline...
java2d@JAVADESKTOP.ORG wrote:
> Sorry, fixed now.
>
> And several questions about the code.
>
> 1. Save/Restore of transformation in Graphics2D. Is this way:
>
> AffineTransform saved = g2d.getTransform();
> ...
> g2d.setTransform(saved);
>
> efficient???
It works well for 1 or 2 attributes, but if you are going to save more
than that then this way is simpler and still fast:
Graphics2D g2 = g.create();
g2.set<Attribute[s](...);
g2.drawandfillstuff(...);
g2.dispose();
Some people may find that model simpler even for one attribute. A lot
of work went into making Graphics2D.create() very fast since Swing uses
that method a lot.
> 2. Fill/Draw functions. I often use fill and draw functions for the same path. Can this somehow be optimized? In Qt there is only one call to QPainter::drawPath and it simultaneously uses current pen for outline and current brush for filling.
We don't have any fill and draw convenience functions or separate fill
and draw paint attributes. I don't think I've seen any feature requests
for these before either.
> 3. I didn't find Path2D.arcTo and used Path2D.append(new Arc2D.Double(...), true). Is this intended way to add arc to path?
> [Message sent by forum member 'kamre' (kamre)]
Yes, that is the only way to add an arc to a path currently. There was
a suggestion to add that method to GeneralPath (now just a subclass of
Path2D), but it never received any votes in the bug parade in over a decade:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4080460
...jim
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 25, 2008 9:01 PM
in response to: Jim Graham
|
|
|
Jim, thank you for anwsers.
By the way I have slightly improved performance by turning off antialiasing for fill operation if it is followed by draw operation for the same path. It seems that there is no sense to antialias fill in such cases. Also some correction for computation of bounds of gradient was made in order to better correspond to Qt version. Results are here: http://trac-hg.assembla.com/jgears/wiki#Java2D
|
|
|
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 26, 2008 8:25 AM
in response to: linuxhippy
|
|
|
Nice job. Worked on my Win2K box with no native acceleration.
Java 6u10. Got about 14-15 fps anti-alias -- 24-25 fps not.
Noticed that when Gears is iconified it continues to run
at full throttle taking 100% of my CPU.
java2d@JAVADESKTOP.ORG wrote:
> *laughing*
> Just did the same thing a month ago: http://linuxhippy.blogspot.com/2008/11/jgears2-rendermark.html
> [Message sent by forum member 'linuxhippy' (linuxhippy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=318832
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 26, 2008 2:10 PM
in response to: linuxhippy
|
|
|
I have only recently found your results from "Swing links of the week" ))
I have run this benchmark on Ubuntu 8.10 and the results are rather strange: only OpenGL pipelines allowed to increase performance for both Qt and Java2D. And even Qt pure software rendering is slower then in WinXP with MinGW compiler. Probably something wrong with blitting images in drivers.
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 28, 2008 7:09 AM
in response to: kamre
|
|
|
> I have only recently found your results from "Swing
> links of the week" ))
Well your version is clearly superior to mine - I won't develop it any further.
Thanks for creating this cool stuff 
> I have run this benchmark on Ubuntu 8.10 and the
> results are rather strange: only OpenGL pipelines
> allowed to increase performance for both Qt and
> Java2D.
> And even Qt pure software rendering is slower
> then in WinXP with MinGW compiler. Probably something
> wrong with blitting images in drivers.
I have no idea why QT's software rendering is faster on Windows-XP compared to Linux.
Maybe QT does not use SHMPut to copy the software-rendered image to a "native" surface, this would cause quite a lot of overhead.
QT/render is so slow in Linux because QT's XRender routines are rather dumb and ignore the fact that only a few paths are accalerated.
However I have an explanation why Java2D is so slow with antialasing enabled:
Java2D guarantees consistent antialiasing quality, therefor it uses a mixed software/hw approach.
The antialiased geometry is generated by the CPU while the blending itself is done on hw.
QT relies on the OpenGL driver's capabilities, but drivers often differ a lot when it comes to quality - however that is slowly changing.
Would be interesting to see results without antialiasing (also of QT) compared.
Thanks, Clemens
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 29, 2008 11:31 AM
in response to: linuxhippy
|
|
|
> Would be interesting to see results without antialiasing (also of QT) compared.
I have added results without antialiasing . Also WinXP NVidia driver was updated to latest version. Rather strange result for Java2D in Ubunutu with opengl=false.
> However I have an explanation why Java2D is so slow with antialasing enabled:
> Java2D guarantees consistent antialiasing quality, therefor it uses a mixed software/hw approach. The antialiased geometry is generated by the CPU
> while the blending itself is done on hw. QT relies on the OpenGL driver's capabilities, but drivers often differ a lot when it comes to quality -
> however that is slowly changing.
Thanks for this explanation.
There is no pixel-to-pixel correspondence when Qt OpenGL pipeline is enabled (I have taken two screenshots, there is only a subtle difference). With good enough drivers (like NVidia on Windows for example) usage of hardware acceleration improves performance about 4.4 time for my configuration (7600GS AGP is rather old). So having the option for usage of OpenGL driver's capabilities is a very good thing. And why there is no such option for Java2D?
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 30, 2008 2:42 PM
in response to: kamre
|
|
|
Hi again,
> I have added results without antialiasing . Also
> WinXP NVidia driver was updated to latest version.
> Rather strange result for Java2D in Ubunutu with
> opengl=false.
Thanks a lot, very interesting data
The "old" X11 pipeline (Linux, no OpenGL) has quite a hard time with modern drivers, with the upcoming 180.* drivers you'll see even worse performance.
I am working on a new pipeline, improving the performance of non-opengl rendering on Unix:
http://linuxhippy.blogspot.com/
> There is no pixel-to-pixel correspondence when Qt
> OpenGL pipeline is enabled (I have taken two
> screenshots, there is only a subtle difference). With
> good enough drivers (like NVidia on Windows for
> example) usage of hardware acceleration improves
> performance about 4.4 time for my configuration
> (7600GS AGP is rather old). So having the option for
> usage of OpenGL driver's capabilities is a very good
> thing. And why there is no such option for Java2D?
Hmm, I am not from Sun so I don't know why Java2D doesn't offer such a quick&dirty mode.
It would probably quite useful for games - however games often use pre-rendered images anyway.
However to be honest I was quite disappointed about the quality QT+OpenGL shows on your screenshot.
It was my belief that modern hardware (like your GF7) in combination with latest drivers would behave much better from what I have seen from 5-year ago hardware, but still quality isn't reliable.
Its ok for games, but would you really build a user-interface on top of that, where you have a lot of tiny lines and small primitives?
- Clemens
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 6:21 AM
in response to: linuxhippy
|
|
|
> However to be honest I was quite disappointed about the quality QT+OpenGL shows on your screenshot.
> It was my belief that modern hardware (like your GF7) in combination with latest drivers would behave much better from what I have seen from 5-year ago hardware, but still quality isn't reliable.
> Its ok for games, but would you really build a user-interface on top of that, where you have a lot of tiny lines and small primitives?
Quote from Qt mailing list:
> Just to clarify this: when using a QPainter on a QGLWidget we rely
> entirely on the multisampling capabilities of your GL implementation to
> handle antialiasing of all primitives that are drawn. If your GL
> implementation doesn't support multisampling you don't get any
> antialiased primitives. If you have a good graphics card that e.g.
> supports 8 times multisampling, you will get decent results (although
> not comparable in quality to e.g. the raster engine).
But there is an option to use QGLWidget only for some particular part of user interface. I want to create application with main part representing vector graphics (so called zoomable user interface, manipulation with a lot of objects inside scene). So such type of antialiasing is quite ok for one particular widget, all the other user interface elements can use high quality software rendering. Is there a component for Java2D with quick&dirty mode? Maybe JOGL can help?
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 8:23 AM
in response to: kamre
|
|
|
I've heard about http://slick.cokeandcode.com/index.php .
However you can try to cache rendering in images which you transform, thats usually very cheap with D3D/OGL.
- Clemens
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 8:58 AM
in response to: linuxhippy
|
|
|
Thank you for the link. I will look at this library and probably will rewrite fancy gears with help of it.
Caching images is not very usefull when smooth zoom is used. Though it can help to improve performance for scrolling I think.
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 10:51 AM
in response to: linuxhippy
|
|
|
On Nov 30, 2008, at 2:42 PM, java2d@JAVADESKTOP.ORG wrote:
>> There is no pixel-to-pixel correspondence when Qt
>> OpenGL pipeline is enabled (I have taken two
>> screenshots, there is only a subtle difference). With
>> good enough drivers (like NVidia on Windows for
>> example) usage of hardware acceleration improves
>> performance about 4.4 time for my configuration
>> (7600GS AGP is rather old). So having the option for
>> usage of OpenGL driver's capabilities is a very good
>> thing. And why there is no such option for Java2D?
> Hmm, I am not from Sun so I don't know why Java2D doesn't offer such
> a quick&dirty mode.
> It would probably quite useful for games - however games often use
> pre-rendered images anyway.
>
> However to be honest I was quite disappointed about the quality QT
> +OpenGL shows on your screenshot.
> It was my belief that modern hardware (like your GF7) in combination
> with latest drivers would behave much better from what I have seen
> from 5-year ago hardware, but still quality isn't reliable.
> Its ok for games, but would you really build a user-interface on top
> of that, where you have a lot of tiny lines and small primitives?
Yeah, we've experimented with native multisampling (in the OGL-based
Java 2D pipeline, mainly) periodically over the past 5 or 6 years. In
the earlier days, both performance and quality of hardware
multisampling were very poor and as such it wasn't worth considering.
Since then, performance has improved quite a bit, but as Clemens said,
quality is still quite poor by our standards, even with e.g. 8x
multisampling. The quality of hardware multisampling has generally
been too poor to consider exposing even a "quick-and-dirty" mode,
although that would make an interesting OpenJDK research project if
anyone's up for the challenge.
In our hardware accelerated pipelines, our first priority was to
provide antialiased rendering quality in line with what our existing
software renders produce. Since then, we've started to use pixel
shaders to provide our own high-quality antialiased fast paths for
certain primitives, such as lines and rectangles, and that's just the
beginning. For example, see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6690659
Thanks,
Chris
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 4:32 AM
in response to: kamre
|
|
|
Hi again,
I experience deadlocks from time to time. Maybe it could help to create the JGears object on the EDT?
Found one Java-level deadlock:
=============================
"AWT-EventQueue-0":
waiting to lock monitor 0x09495438 (object 0xaeede358, a JGears),
which is held by "main"
"main":
waiting for ownable synchronizer 0xaeee5410, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
which is held by "AWT-XAWT"
"AWT-XAWT":
waiting to lock monitor 0x09495438 (object 0xaeede358, a JGears),
which is held by "main"
Java stack information for the threads listed above:
===================================================
"AWT-EventQueue-0":
at java.awt.Frame.getExtendedState(Frame.java:810)
- waiting to lock <0xaeede358> (a JGears)
at javax.swing.RepaintManager.addDirtyRegion0(RepaintManager.java:428)
at javax.swing.RepaintManager.addDirtyRegion(RepaintManager.java:485)
at javax.swing.JFrame.repaint(JFrame.java:777)
at java.awt.Component.repaint(Component.java:3028)
at java.awt.Component.repaintParentIfNeeded(Component.java:2096)
at java.awt.Component.reshape(Component.java:2084)
- locked <0xaeecddb0> (a java.awt.Component$AWTTreeLock)
at javax.swing.JComponent.reshape(JComponent.java:4182)
at java.awt.Component.setBounds(Component.java:2027)
at java.awt.BorderLayout.layoutContainer(BorderLayout.java:838)
- locked <0xaeecddb0> (a java.awt.Component$AWTTreeLock)
at java.awt.Container.layout(Container.java:1477)
at java.awt.Container.doLayout(Container.java:1466)
at java.awt.Container.validateTree(Container.java:1564)
at java.awt.Container.validate(Container.java:1536)
- locked <0xaeecddb0> (a java.awt.Component$AWTTreeLock)
at java.awt.Window.dispatchEventImpl(Window.java:2557)
at java.awt.Component.dispatchEvent(Component.java:4317)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:604)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
"main":
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xaeee5410> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:769)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:802)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1132)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
at sun.awt.SunToolkit.awtLock(SunToolkit.java:269)
at sun.awt.X11.XWindowPeer.setReparented(XWindowPeer.java:1343)
at sun.awt.X11.XDecoratedPeer.setResizable(XDecoratedPeer.java:884)
at java.awt.Frame.setResizable(Frame.java:627)
- locked <0xaeede358> (a JGears)
at JGears.<init>(JGears.java:62)
at JGears.main(JGears.java:66)
"AWT-XAWT":
at java.awt.Component.getName(Component.java:816)
- waiting to lock <0xaeede358> (a JGears)
at java.awt.Component.paramString(Component.java:7711)
at java.awt.Container.paramString(Container.java:2852)
at java.awt.Frame.paramString(Frame.java:967)
at javax.swing.JFrame.paramString(JFrame.java:861)
at java.awt.Component.toString(Component.java:7731)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at sun.awt.X11.XDecoratedPeer.requestWindowFocus(XDecoratedPeer.java:1170)
at sun.awt.X11.XDecoratedPeer.handleWmTakeFocus(XDecoratedPeer.java:1041)
at sun.awt.X11.XDecoratedPeer.handleClientMessage(XDecoratedPeer.java:1034)
at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1074)
at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1056)
at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:499)
at sun.awt.X11.XToolkit.run(XToolkit.java:594)
at sun.awt.X11.XToolkit.run(XToolkit.java:529)
at java.lang.Thread.run(Thread.java:674)
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 5:50 AM
in response to: linuxhippy
|
|
|
Do you mean something like this:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
JGears fancyGears = new JGears();
fancyGears.setVisible(true);
}
});
?
I have updated the code.
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Dec 1, 2008 8:20 AM
in response to: kamre
|
|
|
Thanks, I'll try it soon
|
|
|
|
|
|
|
|
|
Re: [JAVA2D] Poor performance of Java2D
Posted:
Nov 26, 2008 8:57 AM
in response to: kamre
|
|
|
One other minor thing I've noticed: in Renderer.paint
move the setting of the AA hint to after fillRect call which
fills the bg. No need to have AA set when filling the
background.
Won't help a whole lot though.
Thanks,
Dmitri
java2d@JAVADESKTOP.ORG wrote:
> Jim, thank you for anwsers.
>
> By the way I have slightly improved performance by turning off antialiasing for fill operation if it is followed by draw operation for the same path. It seems that there is no sense to antialias fill in such cases. Also some correction for computation of bounds of gradient was made in order to better correspond to Qt version. Results are here: http://trac-hg.assembla.com/jgears/wiki#Java2D
> [Message sent by forum member 'kamre' (kamre)]
>
> http://forums.java.net/jive/thread.jspa?messageID=318756
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
|
|
|
|
|
java.net RSS
