Re: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA
> One thing that might explain the difference is whether or not the opaque > destinations are considered premultiplied or not. I believe that we > consider them non-premultiplied in which case the extraalpha is multiplied > in, the result is stored to the destination, which involves dividing the > alpha back out == no change. If the system treats the destinations as > premultiplied then it multiplies the alpha into the color, then stores the > multiplied (which looks faded) result into the destination... Yes, I guess XRender treats the destination as premultiplied - at least I guess it does not divide out the alpha at all. Thanks a lot for the explanation :) Thanks, Clemens
Re: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA
Clemens Eisserer wrote: "Extra alpha" has the same behavior for all AlphaComposite instances. In a nutshell, the extra alpha value gets logically multiplied with the source before the actual compositing operation. The AlphaComposite docs explain this process in great detail (look for the A[sub]ac factor): http://java.sun.com/javase/6/docs/api/java/awt/AlphaComposite.html Thanks for the explanation. I guess the reason for the behaviour I see is a xserver-bug ... I am not really sure what to do about it till now. One thing that might explain the difference is whether or not the opaque destinations are considered premultiplied or not. I believe that we consider them non-premultiplied in which case the extraalpha is multiplied in, the result is stored to the destination, which involves dividing the alpha back out == no change. If the system treats the destinations as premultiplied then it multiplies the alpha into the color, then stores the multiplied (which looks faded) result into the destination... ...jim
Re: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA
Hi Chris, > I'm not sure the process you need to follow to get commit access to it > (maybe you could ask Mark Reinhold about that on a separate alias, like the > discuss alias?). Thanks for the hint, Mark sent me the registration invitation. > Do you know which Blit loop is being called in its place? (You can use > -Dsun.java2d.trace=log to get an idea, or you can just step through the > Blit.getFromCache() method.) I suspect there is another, more specific Blit > loop that's already registered that is being found before the one you > registered, but that's just a guess. Ah, that was a bit weird ;) With xorg-server-1.3 I hit a slow-path in the xserver, so I thought that would cause the same slowness in Java2D's FadeAnim. With xorg-server-1.5 my test was fast but FadeAnim was still slow, because it uses getSubImage() for the surfing duke. I changed the FadeAnim demo a bit to not use getSubImage() anymore and now it performs as expected, also the OGL/D3D pipelines should benefit from that change. Is there interest to include that small improvement? If not, no problem of course ;) > "Extra alpha" has the same behavior for all AlphaComposite instances. In a > nutshell, the extra alpha value gets logically multiplied with the source > before the actual compositing operation. The AlphaComposite docs explain > this process in great detail (look for the A[sub]ac factor): > http://java.sun.com/javase/6/docs/api/java/awt/AlphaComposite.html Thanks for the explanation. I guess the reason for the behaviour I see is a xserver-bug ... I am not really sure what to do about it till now. Owen Taylor described it as: > (Pixman of course, does fetch transparent, - it's just that a > transparent source gives you black for operator=Src and an opaque > target.) I paint the scanlines and lines to an alpha-mask which I use later for composition. Instead of transparent for the (1- extra-alpha) part I get black, thats why the result differs. Thanks, Clemens
Re: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA
Hi Clemens, On Jul 15, 2008, at 3:28 PM, Clemens Eisserer wrote: Hi again, - The Xrender-pipeline now is almost able to run common swing applications, copyArea and some bugs are still waiting to be killed, but more or less it should work after. Its only the "hack" release where I tried all the stuff out and I plan to rewrite it starting next week or so, but it would be great if I could upload it to the OpenJDK repository. What should I do to get access to it? There's an hg repository already set up for your Xrender project: http://hg.openjdk.java.net/xrender/xrender/ I'm not sure the process you need to follow to get commit access to it (maybe you could ask Mark Reinhold about that on a separate alias, like the discuss alias?). In theory that should be your sandbox (a child of the jdk7 master repository) as you work to stabilize your new pipeline. - My blit-functions currently are not called if composition with extra-alpha is requested, although I have registered my Blits with CompositeType.AnyAlpha. Are there further requirements to get this accalerated? Do you know which Blit loop is being called in its place? (You can use -Dsun.java2d.trace=log to get an idea, or you can just step through the Blit.getFromCache() method.) I suspect there is another, more specific Blit loop that's already registered that is being found before the one you registered, but that's just a guess. - How does ExtraAlpha influence composition for operators other than SRC_OVER? For now I implement extra-alpha as a 1x1 A8 mask, however although the results are consistent when SRC_OVER is used, when SRC is used the image gets darker and darker the lower the EA value becomes with Xrender, but the RI seems to ignore the the extra-alpha value set. "Extra alpha" has the same behavior for all AlphaComposite instances. In a nutshell, the extra alpha value gets logically multiplied with the source before the actual compositing operation. The AlphaComposite docs explain this process in great detail (look for the A[sub]ac factor): http://java.sun.com/javase/6/docs/api/java/awt/AlphaComposite.html Chris Thank you in advance, lg Clemens Blog: http://linuxhippy.blogspot.com/
[OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA
Hi again, - The Xrender-pipeline now is almost able to run common swing applications, copyArea and some bugs are still waiting to be killed, but more or less it should work after. Its only the "hack" release where I tried all the stuff out and I plan to rewrite it starting next week or so, but it would be great if I could upload it to the OpenJDK repository. What should I do to get access to it? - My blit-functions currently are not called if composition with extra-alpha is requested, although I have registered my Blits with CompositeType.AnyAlpha. Are there further requirements to get this accalerated? - How does ExtraAlpha influence composition for operators other than SRC_OVER? For now I implement extra-alpha as a 1x1 A8 mask, however although the results are consistent when SRC_OVER is used, when SRC is used the image gets darker and darker the lower the EA value becomes with Xrender, but the RI seems to ignore the the extra-alpha value set. Thank you in advance, lg Clemens Blog: http://linuxhippy.blogspot.com/
