[ANNOUNCE] xf86-video-intel 2.99.905

[Chris Wilson]

On Thu, Oct 31, 2013 at 08:29:02AM +0000, Chris Clayton wrote:
> Hi again.
> 
> On 10/30/13 17:12, Chris Clayton wrote:
> > Hi Chris,
> > 
> > I've been trying out this driver and have been getting some text rendering problems on my KDE-3.5.10 desktop. I've also
> > grabbed the tar ball of the latest git version of the driver (ed282456240cc0a7ae9a235ea8aea14a8b8a54ef) and get the same
> > problem. I do not see the problem with 2.99.904.
> > 
> > The problem is that if I open a new konqueror window, place the mouse cursor in it and then scroll the window contents
> > with the mouse wheel, I get text in the window decorations at the bottom of the window. I've attached a snapshot of an
> > affected konqueror window (hope it gets through your and X.org's mail filters). Sometimes the text also spills out on to
> > the desktop itself and remains there until that part of the screen is refreshed for some reason - e.g. drag a window
> > onto and then off the area. I have a snapshot of that too and can send it if it would help, although I guess that's
> > unlikely.
> > 
> >  Do you have any immediate ides which change might be the "culprit" and I could try reverting? If not, I can clone the
> > git tree and do a bisect.
> > 
> 
> I've done a bisect and I ended up with:
> 
> ec0866e86d365ae3fd9790b1b263d49fc4981220 is the first bad commit
> commit ec0866e86d365ae3fd9790b1b263d49fc4981220
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Wed Oct 16 22:39:54 2013 +0100
> 
>     sna/glyphs: Fix computation of extents for long strings
> 
>     And make sure we consider such overflowing strings for correct clipping
>     against Windows.
> 
>     To offset the cost of doing a full extents check (~10% on aa10text), we
>     introduce an approximate extents query (~1% on aa10text). The disparity
>     should be rare, and should be an overestimate to force redundant
>     clipping.
> 
>     Reported-by: Clemens Eisserer <linuxhippy at gmail.com>
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70541
>     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> :040000 040000 9f18aa33be6c0af2cd6e527943efa8dfe401c7cb 65a7be4deacaacc9c6f90a911317f40b37299bf4 M      src
> 
> Unfortunately, the commit doesn't revert cleanly and looks a bit too complex for me to start hacking out. However, I
> have confirmed that a driver built from a tarball up to and including the preceding  does not have the problem, whereas
> one built from the tarball that includes up to and including this commit does.

That's odd as that regression was fixed shortly after

commit f81a7f7192a821654bc72a6b34625a6367cb8479
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Fri Oct 18 09:19:14 2013 +0100

    sna/glyphs: Remove glyph_approx_extents
    
    It didn't consider the height of the glyph above the baseline, i.e. it
    was fundamentally flawed. The only thing to do is to make sure that
    glyph_extents() is sufficiently fast never to show up in profiles.
    (Until then QA should spot the ~10% regression.) An alternative would be
    to feed the drawable clip extents to the render engine and avoid manual
    clipping if the clip region covers the whole drawable.
    
    Reported-by: Clemens Eisserer <linuxhippy at gmail.com>
    Reported-by: Jiri Slaby <jirislaby at gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70552
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>


But the description of your symptoms does match up with
https://bugs.freedesktop.org/attachment.cgi?id=87766

Can you please verify that you have tested with the latest? An Xorg.0.log
would be the best proof.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre