Bug 29401 - Regression: rendering corruption (z-order problems) with fvwm menus
Summary: Regression: rendering corruption (z-order problems) with fvwm menus
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Eric Anholt
QA Contact: Xorg Project Team
Depends on:
Reported: 2010-08-04 12:03 UTC by Nick Bowler
Modified: 2011-06-16 05:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Screen capture with arrows pointing to the artifacts. (209.49 KB, image/png)
2010-08-04 12:03 UTC, Nick Bowler
no flags Details
New menu artifacts. (59.66 KB, image/png)
2011-06-08 18:48 UTC, Nick Bowler
no flags Details
Correctly rendered menu. (31.97 KB, image/png)
2011-06-08 18:49 UTC, Nick Bowler
no flags Details
Sample FVWM config (1011 bytes, text/plain)
2011-06-09 08:25 UTC, Nick Bowler
no flags Details

Description Nick Bowler 2010-08-04 12:03:55 UTC
Created attachment 37575 [details]
Screen capture with arrows pointing to the artifacts.

Some of the rendering on obscured windows in FVWM menus is showing up on top of
other stuff.  It's hard to describe, hopefully the attached screen capture
demonstrates what's happening: there are two black triangles (part of the
partially obscured window) which are showing up on top of the sub-menu window.

I'm running latest git everything.

This is a regression from xf86-video-intel-2.12.0, bisection results follow.

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
We cannot bisect more!

Since the second is a simple fixup of the first, I'll add the log message from
the first commit:

commit feff2ec80eeeba5074d19efcddf4867adf639b4f
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Jul 5 09:07:08 2010 +1000

    uxa: don't compare planemask with FB_ALLONES.
    planemask is an unsigned long initialised to ~0, on 64-bit this is not equal
    to an (unsigned int)-1.
    Use the macro provided to do this.
    Signed-off-by: Dave Airlie <airlied@redhat.com>

git bisect start
# bad: [622e600069ab0efd22586c7a71eecbd4baf21c40] display: Cache whether we have probed for an EDID
git bisect bad 622e600069ab0efd22586c7a71eecbd4baf21c40
# good: [ca16e3133658504b68a6b5c83bb8712899016544] Update version to 2.12.0
git bisect good ca16e3133658504b68a6b5c83bb8712899016544
# bad: [7a4bfaf42412f373bbc8ebe1536018dcacde7436] intel: respect tiling disable.
git bisect bad 7a4bfaf42412f373bbc8ebe1536018dcacde7436
# bad: [75850e824bd66b961b9ce21696d9090169f7b28f] Add mbp_backlight support.
git bisect bad 75850e824bd66b961b9ce21696d9090169f7b28f
# good: [17884af4eda01c05e7429ed6a195f3e4ceeff892] Repair the damage to 'make distcheck' after splitting out i810
git bisect good 17884af4eda01c05e7429ed6a195f3e4ceeff892
# good: [afcd41820d7481912b49093670e9d7a4a6a2338f] Reduce front buffer stride prior to rejection
git bisect good afcd41820d7481912b49093670e9d7a4a6a2338f
# skip: [feff2ec80eeeba5074d19efcddf4867adf639b4f] uxa: don't compare planemask with FB_ALLONES.
git bisect skip feff2ec80eeeba5074d19efcddf4867adf639b4f
# bad: [a2aa4c23f65b03c389c2ba8eac0298dfb205e67d] uxa: oops typo in previous commit
git bisect bad a2aa4c23f65b03c389c2ba8eac0298dfb205e67d
# good: [7ad9c0bebf2c71db574e0302264859ce53cecd37] add cscope files to gitignore
git bisect good 7ad9c0bebf2c71db574e0302264859ce53cecd37
Comment 1 Chris Wilson 2010-08-04 12:09:52 UTC
Looks like Dave's patch uncovered the bug in that my code doesn't appear to be honouring clipping correctly. Thanks.
Comment 2 Eric Anholt 2011-06-08 15:48:06 UTC
The bug Chris was referring to (I think) is fixed in:

commit e0066e77e026b0dd0daa0c3765473c7d63aa6753
Author: Eric Anholt <eric@anholt.net>
Date:   Tue May 31 23:17:16 2011 -0700

    uxa: Simplify Composite solid acceleration for spans by only clipping once.
    Unlike the previous commit removing this style of code, the code in
    this one was originally wrong, and would fail to clip in the second
    pass of clipping when y was > pbox->y2.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37233
    Reviewed-by: Keith Packard <keithp@keithp.com>
Comment 3 Nick Bowler 2011-06-08 18:48:10 UTC
Created attachment 47743 [details]
New menu artifacts.

Unfortunately, it appears that the issue is not quite fixed.  While the
triangles no longer render on top of other menus, now they sometimes don't
render at all.  After opening and closing a bunch of submenus (which
temporarily obscures some of the triangles), I end up with a menu that's
missing bits.  The triangles reappear spontaneously as you select various menu

Just to clarify: there are no problems with the menus prior to the commit
implicated in the original post.
Comment 4 Nick Bowler 2011-06-08 18:49:10 UTC
Created attachment 47744 [details]
Correctly rendered menu.

For reference, here's what the menu is _supposed_ to look like.
Comment 5 Chris Wilson 2011-06-09 02:44:23 UTC
Nick, I need a few more instructions on driving FVWM to reproduce your menus. I think these were all fixed with sna..
Comment 6 Nick Bowler 2011-06-09 08:25:55 UTC
Created attachment 47774 [details]
Sample FVWM config

(In reply to comment #5)
> Nick, I need a few more instructions on driving FVWM to reproduce your menus.

The attached config file can be used to reproduce the issue.  After
experimenting a bit, I've discovered that the issue is most easily reproduced
by opening the menu on the right hand side of the screen, so that the submenus
open to the *left* of the main menu.  It then becomes apparent that the
triangles in the main menu will disappear if they are forced to be redrawn
(e.g. by highlighting a menu item) and they are either to the right or below
the submenu (triangles above the submenu are not affected, and I'm not sure if
it's possible for triangles to appear to the left of a submenu).

> I think these were all fixed with sna..

Indeed, enabling sna appears to fix the menus, but of course you need an
X server release from the future (else apply patches from the mailing list)
to use that.
Comment 7 Chris Wilson 2011-06-16 05:42:34 UTC
The code is gone:

commit 855ced5a4eb67e287001ae22cb6489639c548cfa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jun 16 13:24:14 2011 +0100

    uxa: Remove the attempt to use the 3D pipeline for core rendering
    The attempt was still ridden with bugs, such as
    A fresh approach was taken with SNA, but in the mean time before that
    can be enabled downstream, restore correct behaviour.
    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.