[ANNOUNCE] xf86-video-intel 2.99.905

[Chris Clayton]

Hi Chris.

On 10/31/13 16:09, Chris Clayton wrote:
> 
> 
> On 10/31/13 13:58, Chris Wilson wrote:
>> 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.
>>>>

Another data point. Over the weekend I was compiling an update to ImageMagick. In fact I was compiling it on my desktop
and my laptop at the same time, with the konsole window from the desktop opened on the laptop (via DISPLAY=laptop:0).
The attached screenshot shows that the leakage I described in my original email can happen horizontally as well as
vertically.

Would it be useful if I opened a bugzilla report for this problem?

Chris
>>>>  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.
> 
> Attached are two Xorg.0.log files. As the names indicate, one is for the released 2.99.905 driver and the other is for a
> driver up to and including 82e6d41c2f4f343bd1854d3d8ee4b624b5d68971, which, 30 minutes or so ago, was the latest commit.
> Both drivers exhibit the problem I described yesterday.
> 
> Chris
> 
> 
>> -Chris
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CorruptDesktop4.jpg
Type: image/jpeg
Size: 217928 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20131104/baeb3a00/attachment-0001.jpg>