[OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA
linuxhippy at gmail.com
Wed Jul 16 14:17:27 UTC 2008
> 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):
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
I paint the scanlines and lines to an alpha-mask which I use later for
Instead of transparent for the (1- extra-alpha) part I get black,
thats why the result differs.
More information about the 2d-dev