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
