[ANNOUNCE] xf86-video-intel 2.99.905

Chris Wilson chris at chris-wilson.co.uk
Thu Oct 31 14:58:48 CET 2013

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

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

Chris Wilson, Intel Open Source Technology Centre

More information about the xorg mailing list