| Summary: | Progress bars and other dynamic elements do not render properly with SNA enabled | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Eric Appleman <erappleman> | ||||||
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | git | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 59888 [details]
Xorg log
Cairo version and gtk theme? The progress bar just looks like someone was drawing partially overlapping pixmaps, which is exquisite fail. What else do you see wrong? I'm usin Ubuntu's Ambiance theme for GTK. Cairo is 1.12.1. If I arrow through dropdown menus, the bug will also show up. My suspicion is that if you patched cairo not to use PolyModeImprecise by default, or for the theme to request CAIRO_ANTIALIAS_BEST around those elements, the issue would go away. I will need to isolate the error to be sure that the rendering is within spec. Hmm, do you have a repository you use for the extra packages or are compiling cairo by hand? Just trying to reproduce your setup to see if I can reproduce the bug. (Note, I haven't yet reproduced this hence the delay.) I've fixed at least one of the bugs captured in that screenshot, and hopefully the progress bar misrendering as well! Can you please retest and grab a new screenshot if it is still present? (I haven't seen that error in the progress bar myself yet...) Thanks. Here's a video I did up. The wonky rendering behaves differently than before, but it does not look any better. And I forgot the vid... http://www.youtube.com/watch?v=fTP6NtAt0sU&hd=1 Another couple of bugs fixed in the last 10 days. Still no sign of your misrendering here for me to know for sure what I'm trying to fix, so can you please update and see if there is any improvement yet? Everything looks fine after my most recent pull. My guess would be: commit 80567f61afe77a003e663b17c1fc6b6c3ed04042 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon May 14 10:40:38 2012 +0100 sna/trapezoids: Do not reduce SRC to a clear pixmap to unbounded As we instruct the migration code to drop the clear when copying from the GPU to the CPU, we then need to emit the zeros during the span writing. Fixes some occassional corruption behind complex clip masks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> I'm going to tentatively close this, please do reopen at the first sign of trouble. Thanks! The only visual oddity still present is an occasional line of text seeming darker than its surrounding text. Would this be a SNA issue or something to investigate with the FreeType devs? freetype is used by the client to render the individual glyph images. So if the issue is isolated to a single region and the same glyph appears unaffected elsewhere and after redraws, then the problem occurred whilst rendering that particular region and is more likely a driver bug. One telling question is whether you can capture the artifact in a screenshot, otherwise can you grab a camera and take a photograph (preferably with enough resolution to resolve the individual pixels in the glyphs). If the issue persists (take note of any potential reproduction steps!), please open a new bug. |
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.
Created attachment 59887 [details] Screenshot of bug symptoms [ 24.220] (II) intel(0): SNA compiled from 2.18.0-197-g09deba9 [ 24.293] (II) intel(0): SNA initialized with SandyBridge backend