Created attachment 59389 [details] screenshot of the corruptions When moving other windows on top of Java2Ds BullsEyeDemo (same demo as in bug 46415) I get corruptions when using Java2D's xrender backend in the case antialising is turned off. The larger the area covered by the demo is, the more likely it is on my systems that those corruptions turn up. The issue is reproduceable with these steps: - Start Java2Demo with: java -Dsun.java2d.xrender=True -jar Java2Demo.jar (java 7 required, can be checked with java -version) - Open the "Colors"-Tab - Disable antialising by unchecking the checkbox - Double-click on the BullsEyeDemo to make it occupy the whole demo-area - Resize window fullscreen - Move another window on top of the demo My System: Linux-3.3.0 i945GM intel-2.18.0-165-g2d1f3cb
Have you tried different WM? (And which WM is this, just in case that's important?)
window manager doesn't matter as long as its a non-composited environment - happens with icewm too.
Ok, I can reproduce this strange lightening of the bullseye using icewm, however icewm itself looks ok...
Hmm, reading through the debug log is bringing back all the horrors of jxrendermark. :-p I'm totally convinced that reusing the sample temporary pixmap for uploads is a good idea, it requires a lot of work to reduce it to the same code as if you just recreated a pixmap of the right size each time (and I'm not sure if it manages to achieve that reset everytime with the static scratch). </whinge>
Yeah - the antialiased case should match jxrendermark's putimage test - the aliased one should just send tons of small rectangles. I am not really happy how antialiased rendering is done in the java2d-backend, tried a lot of different ways to upload that mask data, but over all the different drivers and acceleration architectures, the current approach worked best. However the intel-driver does really well, consuming aa tiles as fast as they can be created, exa drivers had a harder time last time I tested. For me the fixation on trapezoids as the only way to upload aa coverage data is a really annoying design descision. Those trapezoids are hard to generate - and hard/slow to rasterize too. Pixman's software-rasterizer for trapezoids is more or less "don't touch" code, written in highly cryptic style. And because trapezoids seem so hard to get right/fast, almost all drivers rely on those routines. What would I give for a way to submit RLE coverage data...
Yeah, RLE mask is on my todo list, along with passing paths to Render. Back to the bug, I've identified the path that is wrong; Composite with a solid source and a solid mask. Now to find out why.
commit 04851e4210d2d71542359c14d4b68d0851b36326 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 3 12:34:24 2012 +0100 sna/gen3: Convert the clear-color from picture->format to a8r8g8b8 The shaders treat colours as an argb value, however the clear color is stored in the pixmap's native format (a8, r5g6b5, x8r8g8b8 etc). So before using the value of the clear color as a solid we need to convert it into the a8r8g8b8 format. Reported-by: Clemens Eisserer <linuxhippy@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48204 Reported-by: Paul Neumann <paul104x@yahoo.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47308 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.