Created attachment 59509 [details] Screenshot showing the expected and wrong rendering side-by-side I recently tried x11-libs/cairo-1.12.0 for a short period in order to diagnose what was believed to be a graphics driver issue. The problem is that with many themes, including the well-known clearlooks theme, many user interface controls are missing the rightmost column of pixels. I have attached a screenshot illustrating the issue side-by-side. The left side shows the expected rendering as rendered by 1.10.2-r1 The left side shows the missing pixels on the controls as rendered by x11-libs/cairo-1.12.0 When I raised this with the intel-driver team this was described to me as a "missing stroke to the right of clearlooks button. behavioural change between cairo-1.10 and cairo-1.12". My hardware is a Dell XPS 15 (L502x) laptop, and I am using Gentoo. Please let me know if additional information is required.
I just learned that "clearlooks" is gtk2, right? Which exact version of gtk2 and clearlooks etc? How could I reproduce this? With which widgets does this happen? I can see that the font selector (is that a drop down list?) doesn't have this bug. You said it happens with "many themes". Which? According to pmap, I am using murrine and gvim has no problems here.
(In reply to comment #1) > I just learned that "clearlooks" is gtk2, right? Which exact version of gtk2 > and clearlooks etc? > > How could I reproduce this? With which widgets does this happen? I can see that > the font selector (is that a drop down list?) doesn't have this bug. > > You said it happens with "many themes". Which? According to pmap, I am using > murrine and gvim has no problems here. This could very well be gtk2. Although I currently have both x11-libs/gtk+-2.24.8-r1 and x11-libs/gtk+-3.2.3 installed, the application you see in the screenshot is the xfce 4.8 (xfce-base/xfce4-settings-4.8.3) 'appearence settings dialog'. I think xfce is still based on gtk2. The clearlooks theme seems to belong to x11-themes/gtk-engines-2.20.2. It seems to happen with 'many' widgets, unfortunately I cannot provide you with an extensive list. However at least those shown on the screenshot seems to be always affected. If you look closely you can see that there is a difference in the rendering of the font-selector, too. Midway the bottom edge of the font-selector the edge-color suddenly changes, whereas it does not on the left window. Also the right-most column of pixels of the font-selector is painted differently. I don't know how best to suggest to reproduce this, but the most sure-fire way would perhaps be to try this exact application (xfce4-appearance-settings). In regards to themes, again I cannot offer you an exhaustive list, and sometimes it seems to be that only some controls are affected, or perhaps it's just hard to see, but some clear examples include: - clearlooks - bluman - colorbit and colorbit-2 - creamy - darker theme - glossywinter - halflight - human - ... etc Other themes such as equgrains, fluid, or ges have issues with the rendering of backgrounds or gradients, where strange patterns seem to appear (please let me know if you'd like me to make a screenshot of this). Other themes often misrender the 'close' button and the tabs.
I think I have this fixed, albeit accidentally. And I think the fix is: commit 9417fec04a172a7c44be38c1b3d032c3fee4f0d6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 18 20:44:43 2012 +0100 image: Split inline SRC composition Currently we construct a mask for the entire line and try to process it in one call to pixman (two without the LERP operator). An alternative approach is split the row into separate composite operations for the clear (which we can skip), fully opaque and partial spans. As the source operator is typically mostly opaque or clear, this is a good win as we are able to utilise more fast paths. In the worst case, it degrades to the old method of constructing a whole mask for a row. It may reduce performance for having to process lots of spans though (this is where the pixman spans interface should help). However, such geometry is rare and typically handled elsewhere. And the existing code has a bug where it was clearing the destination for clear regions of the mask outside of the spans.
Truly fixed this time. Found the right set of circumstances to reliably reproduce. commit 6924fc525d6bc82901cfed769c176b44c0bce024 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 11 14:04:09 2012 +0100 sna: Fix off-by-one in computation of width for inplace trapezoids This lead to the dropping of the last pixel for small area trapezoids, such as the right hand outline of buttons under ClearLooks. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48320 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.