Re: [JAVA2D] Poor performance of Java2D
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.(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) [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=319331
Re: [JAVA2D] Poor performance of Java2D
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. [Message sent by forum member 'kamre' (kamre)] http://forums.java.net/jive/thread.jspa?messageID=319342 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Poor performance of Java2D
> 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? [Message sent by forum member 'kamre' (kamre)] http://forums.java.net/jive/thread.jspa?messageID=319345 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Poor performance of Java2D
Thanks, I'll try it soon :) [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=319362 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Poor performance of Java2D
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 [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=319365 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Poor performance of Java2D
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. [Message sent by forum member 'kamre' (kamre)] http://forums.java.net/jive/thread.jspa?messageID=319370 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Print BufferedImage Externally Generated
Thanks for your help Phil. > But > >I'm trying to build up a BufferedImage using its > Graphics component, > nd then print that image using a Printable > Why? As in I don't know why you aren't rendering > directly to the printer ? I have a builder for my non-print documents, but it seems that I can't apply the normal builder to a printer document because of the way java print services works. If I were to apply the builder directly to the printer, it seems that I would have to somehow enter the print method in the builder and then have the director call the builder while it was in the print method, but that's not possible. So instead, I'm trying to build an image and pass it to the printable. But as you have pointed out, this is not a nice solution. Any advice? > The clipping is because the imageable area of the > paper may be less than > the physical size of the paper. > You need to get the imageable area from the > PageFormat and then scale > your rendering (ie the final image) to fit. > You can also control this by specifying the imageable > area in the > PageFormat but you'll need to use the javax.print > APIs to find out what is the hard liimit for the > device > See > http://java.sun.com/javase/6/docs/api/javax/print/attr > ibute/standard/MediaPrintableArea.html > > But > >I'm trying to build up a BufferedImage using its > Graphics component, > nd then print that image using a Printable > Why? As in I don't know why you aren't rendering > directly to the printer ? > > If you do what you are doing you will get blocky > output, unless you > create a very large image and scale > it to printer resolutions. Even then it means you > won't get printer > fonts etc. > > So I suspect your approach is costing you in > - output quality > - memory used > - performance > > -phil. > > [EMAIL PROTECTED] wrote: > > Hi, I'm trying to build up a BufferedImage using > its Graphics component, and then print that image > using a Printable. The problem is that some of my > operations on the graphics component seem to be lost, > and when I print the image, a lot of it is clipped > off around the borders. The code below shows the > gist of what I'm doing. > > > > // this method is in class A > > foo(String text, Font font, B b, int x, int y) { > > Graphics2D g2d = (Graphics2D) > image.getGraphics(); > > g2d.setColor(Color.black); // this color gets > lost when bar is called > > g2d.setFont(font); // this font gets lost when > bar is called > > b.bar(text, x, y); > > } > > > > // this method is in class B > > bar(String text, int x, int y) { > > Graphics2D g2d = (Graphics2D) > image.getGraphics(); > > g2d.drawString(text, x, y); // this does not get > lost when the image is printed > > } > > > > // this is the print method for the Printable, the > image is passed to the Printable > > print(Graphics g, PageFormat pf, int pageIndex) { > > if (pageIndex == 0) { > > Graphics2D g2d = > (Graphics2D)image.getGraphics(); > > g2d.translate(pf.getImageableX(), > pf.getImageableY()); > > ((Graphics2D)graphics).drawImage(image, null, > 0, 0); > > return Printable.PAGE_EXISTS; > > } else { > > return Printable.NO_SUCH_PAGE; > > } > > } > > > > > > If I hardcode the color and font in the bar method, > then the text actually comes out at the printer, but > if x < 80 or x > 500, it doesn't get printed; same if > y < 80 or y > 600 (these are approximate, I'm just > estimating based on what I printed and where it got > cut off). This leaves about a 1 inch margin around > the printed text on the paper from the printer. > Ultimately, I want to generate a document image > using j2d and send that to the printer. Any help is > greatly appreciated! > > > Thanks in advance! > > [Message sent by forum member 'wtrpirate' > (wtrpirate)] > > > > > http://forums.java.net/jive/thread.jspa?messageID=3189 > 09 > > > > > == > = > > To unsubscribe, send email to [EMAIL PROTECTED] > and include in the body > > of the message "signoff JAVA2D-INTEREST". For > general help, send email to > > [EMAIL PROTECTED] and include in the body of > the message "help". > > > > == > = > To unsubscribe, send email to [EMAIL PROTECTED] > and include in the body > of the message "signoff JAVA2D-INTEREST". For > general help, send email to > [EMAIL PROTECTED] and include in the body of the > message "help". [Message sent by forum member 'wtrpirate' (wtrpirate)] http://forums.java.net/jive/thread.jspa?messageID=319384 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Poor performance of Java2D
On Nov 30, 2008, at 2:42 PM, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: [JAVA2D] Print BufferedImage Externally Generated
[EMAIL PROTECTED] wrote: Thanks for your help Phil. But I'm trying to build up a BufferedImage using its Graphics component, nd then print that image using a Printable Why? As in I don't know why you aren't rendering directly to the printer ? I have a builder for my non-print documents, but it seems that I can't > apply the normal builder to a printer document because of the way java print services works. > If I were to apply the builder directly to the printer, it seems that I would have to somehow > enter the print method in the builder and then have the director call the builder while it was > in the print method, but that's not possible. So instead, I'm trying to build an image and pass > it to the printable. But as you have pointed out, this is not a nice solution. Any advice? Consider that the rendering process first needs to obtain a Graphics instance, either from BufferedImage.createGraphics() or the one passed in to Printable.print(..). I cannot see why your "builder" should know or care what the origin is, nor do I see why you can't call your builder's paint method from print(). -phil. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".