Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Hi Dmitri, thanks for your answer. This is what I was fearing too... I wouldn't mind implementing my UI with JavaFX in other projects, however on this one it would be particularly difficult and unefficient as it is a fullscreen game refreshing hundreds of sprites at 40 frames per sec. JavaFX kind of scenegraph design would require that I rebuild the whole scenegraph at every frame update as it could be very different from one frame to another... I will stick with my current implementation. Just a pity that the PhotoComposite API will not be brought to life by Dolphin ;-) I am still hoping the ADD and MULTIPLY mode will still appear as available hardware accelerated composite mode of the Graphics2D object. Cheers. Vince. [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=342291 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
jav...@javadesktop.org wrote: Hi Jim, I perfectly agree with your analysis. My point was not to have it in the same class as the Porter Duff rules implementation. The only thing I am looking after is having these "advanced blending modes" working with hardware acceleration pipelines. Given the latest evaluation of RFE 6541868, it seems that this will only happen for the ADD mode and maybe for the MULTIPLY mode also. However, for all the other modes, it seems that it is no longer in the plan to implement them as a Composite (was known as PhotoComposite API) that could be given to the Graphics2D object but rather delegated to the use of the JavaFX Blend classes. Unfortunately the JavaFX Blend classes cannot be used without a direct access to the destination surface and in my application I can only draw onto it through the Graphics2D returned by the BufferStrategy. This is why I am trying to understand if there is another way I am not aware of to use the hardware accelerated blending performed by JavaFX classes directly with the BufferStrategy backbuffer without using an additional VolatileImage that would decrease the rendering performances as compared to what we can achieve with page flipping in BufferStrategy. There's no such way that I know of besides implementing your UI in JavaFX. Thanks, Dmitri Any hint ? [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=342252 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help". === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Hi Jim, I perfectly agree with your analysis. My point was not to have it in the same class as the Porter Duff rules implementation. The only thing I am looking after is having these "advanced blending modes" working with hardware acceleration pipelines. Given the latest evaluation of RFE 6541868, it seems that this will only happen for the ADD mode and maybe for the MULTIPLY mode also. However, for all the other modes, it seems that it is no longer in the plan to implement them as a Composite (was known as PhotoComposite API) that could be given to the Graphics2D object but rather delegated to the use of the JavaFX Blend classes. Unfortunately the JavaFX Blend classes cannot be used without a direct access to the destination surface and in my application I can only draw onto it through the Graphics2D returned by the BufferStrategy. This is why I am trying to understand if there is another way I am not aware of to use the hardware accelerated blending performed by JavaFX classes directly with the BufferStrategy backbuffer without using an additional VolatileImage that would decrease the rendering performances as compared to what we can achieve with page flipping in BufferStrategy. Any hint ? [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=342252 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Can ADD and MULTIPLY be expressed using Porter/Duff equations as per the existing rules? I seem to recall that they require clipping the result which none of the other modes require. The P/D chapter in Foley and vanDam mentiones PLUS, but it doesn't describe it in the same terms as the existing table of rules. It is more described as "another useful binary image operation". Keep in mind that the existing P/D rules for AC are all implemented using a single loop at the bottom end that has a tiny variation in it that handles all 12 or so rules in the same piece of code with little structural change. Note that when I say "a single loop" I don't mean a single piece of code that is factored with macros into 12 loops, but a single actual compiled object function that handles all 12 rules. It doesn't even have any decisions in the inner loop for the 12 rules - instead it relies on mathematical similarities of the 12 rules to handle them all with a single computation. So, if you want to add new rules to this matrix, they might not fit into this technique and induce an explosion of the code that handles the AC rules. The technique only really deals well with rules that can be expressed with the 4 standard Fa and Fb functions that are guaranteed not to overflow in the math. If you add rules that are incompatible with that technique then it is more likely that you'll have to special case them and vector them into new inner loops that do whatever clipping/clamping is required for ADD/MUL that isn't required for the regular AC rules. That isn't a huge issue, but it might almost be cleaner to have a new class so we vector into different code paths at a higher level than to have to vector off at a lower level. (Try it and see how it goes). ...jim jav...@javadesktop.org wrote: Hi everyone, quick question more or less related to this topic on hardware accelerated drawing: I was desperately waiting for what was supposed to be called the PhotoComposite API that would allow new blending modes (ADD, MULTIPLY, OVERLAY, ...) to be used as Composite for the Graphics2D API. Unfortunately, it seems that the original plan is no longer in scope as stated in the RFE 6541868 (RFE: hardware acceleration for advanced blending modes (aka PhotoComposite) ): [i]"Therefore, my current inclination is to scale back the changes originally proposed for JDK 7 and instead make small additions to the existing AlphaComposite API with at least an ADD mode since a) that is the most commonly requested blend mode that isn't already provided in AlphaComposite, b) it fits in fairly well with the existing AlphaComposite rules, and c) it can be accelerated easily in both the software and hardware pipelines (without the use of shaders or reading back from the framebuffer in the hardware case). We might also be able to add a simple MULTIPLY mode, but that will require some more investigation. I think this approach (small enhancements to AlphaComposite) would serve the needs of Java2D developers quite well, while keeping the implementation burden low. Developers who want access to extended blend modes can use the Blend class from JavaFX, which offers the right amount of functionality in a form that can be easily accelerated on the GPU."[/i] Having ADD and MULTIPLY as Composite for Graphics2D is much better than nothing as they are usually the most useful "advanced" blending modes. My problem is that I am working with the BufferStrategy to perform fast frame rate in fullscreen mode. And when using the BufferStrategy, I cannot access to the actual offscreen backbuffer to use it with the JavaFX Blend implementation that will give access to the other hardware accelerated blending modes. As stated by Dmitri, using a VI and then drawing it with the BufferStrategy is not really satifying... This is why having the Graphics2D API able to use all the wonderful hardware accelerated drawing features of the JavaFX package would be very nice... If you see some kind of workaround for me to use JavaFX API with the BufferStrategy without using an additional backbuffer, I would be very interested ! Thanks. Vincent. [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=340922 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help". === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Hi everyone, quick question more or less related to this topic on hardware accelerated drawing: I was desperately waiting for what was supposed to be called the PhotoComposite API that would allow new blending modes (ADD, MULTIPLY, OVERLAY, ...) to be used as Composite for the Graphics2D API. Unfortunately, it seems that the original plan is no longer in scope as stated in the RFE 6541868 (RFE: hardware acceleration for advanced blending modes (aka PhotoComposite) ): [i]"Therefore, my current inclination is to scale back the changes originally proposed for JDK 7 and instead make small additions to the existing AlphaComposite API with at least an ADD mode since a) that is the most commonly requested blend mode that isn't already provided in AlphaComposite, b) it fits in fairly well with the existing AlphaComposite rules, and c) it can be accelerated easily in both the software and hardware pipelines (without the use of shaders or reading back from the framebuffer in the hardware case). We might also be able to add a simple MULTIPLY mode, but that will require some more investigation. I think this approach (small enhancements to AlphaComposite) would serve the needs of Java2D developers quite well, while keeping the implementation burden low. Developers who want access to extended blend modes can use the Blend class from JavaFX, which offers the right amount of functionality in a form that can be easily accelerated on the GPU."[/i] Having ADD and MULTIPLY as Composite for Graphics2D is much better than nothing as they are usually the most useful "advanced" blending modes. My problem is that I am working with the BufferStrategy to perform fast frame rate in fullscreen mode. And when using the BufferStrategy, I cannot access to the actual offscreen backbuffer to use it with the JavaFX Blend implementation that will give access to the other hardware accelerated blending modes. As stated by Dmitri, using a VI and then drawing it with the BufferStrategy is not really satifying... This is why having the Graphics2D API able to use all the wonderful hardware accelerated drawing features of the JavaFX package would be very nice... If you see some kind of workaround for me to use JavaFX API with the BufferStrategy without using an additional backbuffer, I would be very interested ! Thanks. Vincent. [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=340922 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Chris Campbell wrote: On Feb 6, 2009, at 5:46 AM, jav...@javadesktop.org wrote: Hi, I'm trying to get straight in my head exactly which graphics rendering surfaces can get hardware accelerated in Java. There seems to be a lot of confusing/half specified information around. Firstly let me state I'm using Java 6u12 on a Windows XP machine. I'm interested in rendering TO surfaces, not copying from, so I'm not too bothered about managed images. As far as I can tell the setup goes like this: 1) Live screen graphics, i.e. Component.getGraphics() : HW accelerated via Direct3D For now I'll just say "yes", but Dmitri could explain the caveats of this when he gets back from vacation. So as Chris mentioned, the short answer is "yes", the long answer is "don't do it if you can help it". This includes the typical double-buffering mechanism of rendering to a VolatileImage and copying it to the screen. Since DirectX 9 doesn't allow rendering directly to the screen, we have to redirect on-screen rendering into an offscreen buffer which is then presented, thus effectively making on-screen rendering double-buffered. This means that if you have a VI back-buffer, when you copy it to the screen it actually is copied to an offscreen surface which is then presented to the screen, making it triple-buffered, which is less efficient. So the conclusion is: use BufferStrategy for double buffering, and never render to the screen directly. Thanks, Dmitri === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Wow, I didn't expect such quick replies! Thanks everyone, your answers are clear and very useful. Thanks for clearing that up. [Message sent by forum member 'fred34' (fred34)] http://forums.java.net/jive/thread.jspa?messageID=330628 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
The question is where the native rasterisation is used vs where the Java rasteriser is used. We don't use LCD rasterisation of either flavour in such cases. There are also limitations to where Microsoft can or do apply cleartype. I've seen it in the distant past although I can't say for certain if it was the circumstances described/discussed here (transforms): http://blogs.msdn.com/ie/archive/2006/08/31/730887.aspx .. and here (intermediate surfaces) in a posting by a MS WPF engineer : http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/a2f093ca-267c-4af2-b35e-13c01eb4854b/ >there are indeed some challenging technical problems behind enabling ClearType on intermediate surfaces. >Basically, the fundamental problem is that ClearType needs a separate alpha value >for each of the three color channels (RGB or BGR in common LCD configurations), >and typical intermediate surface formats such as ARGB or PARGB have only one. >We were able to get around this issue in some cases for WPF V1, >however this wasn't possible for text rendered onto semi-transparent >intermediate surfaces, which are often used to achieve shadow-like effects. >We have received customer feedback similar to yours on this limitation before, >and we are looking into ways to solve it in future. -phil. jav...@javadesktop.org wrote: The sole exception to this is the glyphs from fonts that are in the jre/lib/fonts directory - ie the fonts that ship with Java. For the Windows JRE this means Lucida Sans Regular. There is another, much bigger exception - painting texts on translucent surfaces (when the current SrcOver composite has alpha < 1.0) uses the bundled rasterizer, which is inferior as far as Segoe UI font (default Vista) is concerned. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=330617 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help". === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
> The sole exception to this is the glyphs from fonts > that are in the > jre/lib/fonts directory - ie the fonts > that ship with Java. For the Windows JRE this means > Lucida Sans Regular. There is another, much bigger exception - painting texts on translucent surfaces (when the current SrcOver composite has alpha < 1.0) uses the bundled rasterizer, which is inferior as far as Segoe UI font (default Vista) is concerned. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=330617 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
2) 6u10 added native font rendering to Java. When is this enabled? Is it always used in all pipelines or just in the D3D rendering? Its implemented in a manner independent of pipelines. It wouldn't have been worthwhile to do it in a way that only worked on some surfaces, or that was sucky slow for them. In case that wasn't 100% clear .. As of 6u10, on Windows only, the native system is used to rasterize LCD glyphs and we store these in our regular internal glyph cache. So its completely independent of the final "blitting" step. So you'll get the natively renderered glyphs regardless of what kind of Java2D surface you're rendering to (whether it is a BufferedImage, a VolatileImage, a BufferStrategy, etc) or what rendering pipeline is currently in use (D3D, OGL, GDI, software, etc). The sole exception to this is the glyphs from fonts that are in the jre/lib/fonts directory - ie the fonts that ship with Java. For the Windows JRE this means Lucida Sans Regular. -phil. === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
Chris Campbell wrote: >No, the DirectDraw pipeline no longer exists as of JDK 6u10. If the D3D pipeline is disabled (or can't be enabled due to driver/hardware >problems) we switch back to using GDI for onscreen rendering, and VolatileImages/BufferStrategy then become backed by system >memory surfaces (analogous to BufferedImages, which implies software rendering). By way of clarification, this is because the old DX7 and D3D 9 APIs are different and you can't use both, so we had no choice. 2) 6u10 added native font rendering to Java. When is this enabled? Is it always used in all pipelines or just in the D3D rendering? I'll leave this one for Phil or Igor. Its implemented in a manner independent of pipelines. It wouldn't have been worthwhile to do it in a way that only worked on some surfaces, or that was sucky slow for them. -phil. === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?
On Feb 6, 2009, at 5:46 AM, jav...@javadesktop.org wrote: Hi, I'm trying to get straight in my head exactly which graphics rendering surfaces can get hardware accelerated in Java. There seems to be a lot of confusing/half specified information around. Firstly let me state I'm using Java 6u12 on a Windows XP machine. I'm interested in rendering TO surfaces, not copying from, so I'm not too bothered about managed images. As far as I can tell the setup goes like this: 1) Live screen graphics, i.e. Component.getGraphics() : HW accelerated via Direct3D For now I'll just say "yes", but Dmitri could explain the caveats of this when he gets back from vacation. 2) Swing backbuffer, i.e. VolatileImages/BufferStrategies: Also HW accelerated via Direct3D Yes. 3) BufferedImages: Always software rendering via GDI Not quite. Yes, it's always software rendering, but it's using our own software loops, not GDI. If Direct3D is disabled via sun.java2d.d3d=false, then cases 1) and 2) switch back to a DirectDraw accelerated pipeline, as in Java 1.5. No, the DirectDraw pipeline no longer exists as of JDK 6u10. If the D3D pipeline is disabled (or can't be enabled due to driver/hardware problems) we switch back to using GDI for onscreen rendering, and VolatileImages/BufferStrategy then become backed by system memory surfaces (analogous to BufferedImages, which implies software rendering). So my questions are: 1) Is the above information correct, and if not what do I have wrong? You were pretty close :) 2) 6u10 added native font rendering to Java. When is this enabled? Is it always used in all pipelines or just in the D3D rendering? I'll leave this one for Phil or Igor. Thanks, Chris === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to lists...@java.sun.com and include in the body of the message "help".
