TOM & the others,
sadly that ARGB_PRE trick doesn’t work at all.
I get even bad results. Bad luck :-/
Let’s hope the win32 Java2D team will fix the bug asap.
Well, it’s not really a win32-specific issue (the bug is reproducible with -Dsun.java2d.noddraw=true, which pretty much disables any win32-specific hw acceleration), but the way our software loops do it. You don’t see it on mac because they’re doing it through hw.
Unfortunately, the bug is still there in current build of 1.5.
I’ll see if our opengl pipeline on linux/solaris does any better tomorrow…
trembovetski,
as you know the bug deeply impacts the quality of all java2d-based programs and it’s so sad to hear that it’s also in 1.5.
How can I help to fix it for 1.4.3 and 1.5 ?
Cheers,
Mik
Well, let me just give you my paypal account =)
Seriously, though, you can vote on the bug. I’ll let the engineer who works on this bug know about this thread.
As I’ve explained in some other thread, the bugs chosen to be fixed in patch releases (_01, _02, etc) have to be escalated, or considered extremely important (like security issues). It also depends on how risky the fix is.
It can definitely be fixed in the next maintenance relelase (1.5.1), but it’s still way off.
There’s still some time left for 1.5, so it may get fixed, it depends on a number of factors (how risky is the fix, etc).
In any case, one thing you can do is to vote on the bug, be vocal on 1.5 beta feedback, and suggest a good business case for why this bug is important.
This kind of fix should not be that risky 
Seriously, how can I reach the 1.5 mail lists ?
Cheers,
Mik
Theres no risk at all, so long as the coder doesn’t c0ck up the fix ;D
Damn I should be in risk managment