Bug 49446

Created attachment 60996 [details]
screenshot showing bug

The annoying part is that possibly the rendering is withing spec.. Can you isolate the trapezoids being used to construct the outline and let's have a look at where they do lie on the sample grid.

I'm sorry, but I don't have the knowledge to know how to do that (I am not a developer).  I can try if you tell me how to do it, though :)

If you can find the simplest application with as little drawing as possible that reproduces the scrollbar issue, capture its drawing commands using 'xtrace'. Then the hunt begins to find the trapezoids...

While looking for simple applications, I fired up The Widget Factory (twf) and discovered that quite a lot of the widgets in the oxygen-gtk theme are being drawn incorrectly.  I will attach comparison screenshots to this bug report.

The simplest application that I could find using scrollbars is leafpad.  Let me know what you want me to do with strace.

Created attachment 60997 [details]
The Widget Factory + Oxygen-GTK (how it's supposed to look)

Created attachment 60998 [details]
The Widget Factory + Oxygen-GTK (using SNA driver)

Looking at the Widget Factory screenshots, in each case, the drawing glitches occur on the rightmost edge of the widget.

So long as we are both looking at that pixel at the top and bottom of the right-hand edges, it does look fairly systematic. :)

So, just let me know what you need me to do.

Created attachment 61564 [details]
Screenshot showing similiar problem

I see similar corruption on my g45/g43 when using SNA. I addition, there is progressbar corruption visible.

(In reply to comment #11)
> Created attachment 61564 [details]
> Screenshot showing similiar problem
> 
> I see similar corruption on my g45/g43 when using SNA. I addition, there is
> progressbar corruption visible.

That particular corruption is fixed by:

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>

Wow, this was quite fast! Thanks Chris!

Thinking about the original screenshot once more, it could well be explained by the same bug (sorry Fryderyk). I was considering as a stroke, but if instead it is layers of filled trapezoids, then the glitch on the right hand edge could be the same off-by-one error.

Christian can you give an updated set of drivers a quick test?

Christian which version of cairo do you have? I've just fixed a related bug in cairo-1.12, and noticed that these are GTK+ widgets...

Having applied the bug fixes for Cairo and the right-hand off-by-one rendering bug in SNA, I looked at the differences between SNA and UXA on gen3 and gen6 and concluded that the remaining differences are within the implementation of the antialiasing. Please do reopen if you continue to see a discrepancy as large as captured in the original report. Thanks.

Created attachment 61972 [details]
The Widget Factory + Oxygen-GTK (after SNA driver fix)

Created attachment 61973 [details]
radio button comparison between default (left) and SNA (right) drivers

Here is my report using the Intel SNA driver version 2:2.19.0+git20120521.afdaf184-0ubuntu0sarvatt2~sna from Robert Hooker's PPA (https://launchpad.net/~sarvatt/+archive/intel-sna).

The updated SNA driver does greatly improve the rendering in Oxygen-GTK.  However, there are a couple of issues:

1) The left and right sides of objects are still not 100% even.  If you compare the radio buttons, for example (see comparison screenshot), you can see that the normal rendering (left) is perfectly even between the left and right sides of the widget, whereas the SNA rendering differs on both sides of the widget (the leftmost edge appears too tall and the rightmost edge appears too short).  You can also see unevenness in the rendering of the black dot in the middle (see how proportional it is in the normal rendering).

2) As seen in the "after SNA driver fix" screenshot, the right and bottom active tabs are not drawn correctly.  With the new SNA driver, the active tab appears to be beneath the tab window area instead of merged with it (compare with the "how it's supposed to look" screenshot).

I don't know if this is helpful for reproducing these results, but I am using the Blue Lilac color scheme in KDE (http://kde-look.org/content/show.php/Blue+Lilac?content=143331)

And an important question is which version of cairo?

The tab overdraw appears to be a cairo regression.

This was using Cairo 1.12.3+git20120521.aed94a5b from the Xorg-edgers PPA.

cairo commit c09be681123388d562822d677db631101a8faa07
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 23 11:38:07 2012 +0100

    bo-rectangular: Emit subsummed boxes for overlapping edges
    
    Fixes bug-bo-collins
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49446
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The actual rendering is within spec, and is probably just an artifact of how cairo flattens the curve (which will only be at best rotationally symmetric).

If we look closely the source of the asymmetry appears to be in cairo:

000:<:0010:344: RENDER-Request(148,10): Trapezoids op=Src(0x01) src=0x00200004 xSrc=40 ySrc=37 dst=0x00200003 maskFormat=0x00000024 trapezoids={top=37.000000 bottom=37.187500 left={x1=40.000000 y1=37.000000 x2=38.898438 y2=37.187500}; right={x1=40.000000 y1=37.000000 x2=41.101562 y2=37.187500};},{top=37.187500 bottom=37.750000 left={x1=38.898438 y1=37.187500 x2=37.937500 y2=37.750000}; right={x1=41.101562 y1=37.187500 x2=42.062500 y2=37.750000};},{top=37.750000 bottom=38.687500 left={x1=37.937500 y1=37.750000 x2=37.257812 y2=38.687500}; right={x1=42.062500 y1=37.750000 x2=42.742188 y2=38.687500};},{top=38.687500 bottom=40.000000 left={x1=37.257812 y1=38.687500 x2=37.000000 y2=40.000000}; right={x1=42.742188 y1=38.687500 x2=43.000000 y2=40.000000};},{top=40.000000 bottom=41.312500 left={x1=37.000000 y1=40.000000 x2=37.257812 y2=41.312500}; right={x1=43.000000 y1=40.000000 x2=42.742188 y2=41.312500};},{top=41.312500 bottom=42.250000 left={x1=37.257812 y1=41.312500 x2=37.937500 y2=42.250000}; right={x1=42.742188 y1=41.312500 x2=42.062500 y2=42.250000};},{top=42.250000 bottom=42.812500 left={x1=37.937500 y1=42.250000 x2=38.898438 y2=42.812500}; right={x1=42.062500 y1=42.250000 x2=41.101562 y2=42.812500};},{top=42.812500 bottom=43.000000 left={x1=38.898438 y1=42.812500 x2=40.000000 y2=43.000000}; right={x1=41.101562 y1=42.812500 x2=40.000000 y2=43.000000};};

The left-edge of the circle is indeed flatter than the right...

I tell a lie, those values are fine, it is in the projection of those values onto the sample grid where the error lies.

commit ae2be7e25bda46551381c19a673b321b4382e1f9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu May 24 16:33:27 2012 +0100

    sna/trapezoids: Correct rounding for downsampling onto sample grid
    
    Reported-by: S. Christian Collins <s_chriscollins@hotmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49446
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>