Created attachment 48500 [details]
window with white border

Created attachment 48501 [details]
my system spec

Seen this, those window borders are definitely not being drawn through X... Grr.

Also note that only unity/compiz seems to provoke these. If you can reproduce similar artifacts with other WM, that would be useful information.

*** Bug 38021 has been marked as a duplicate of this bug. ***

There is very little point debugging these whilst unity is in such a state of disrepair. valgrind has a lot to say about their rendering code, and everything else.

As far as I can tell, this is unity-window-decorator either performing an invalid operation or using an invalid texture. The impact of sna suggests that it is timing related, but afaict not an artifact of sna.

(In reply to comment #7)
> As far as I can tell, this is unity-window-decorator either performing an
> invalid operation or using an invalid texture. The impact of sna suggests that
> it is timing related, but afaict not an artifact of sna.

Thanks for taking the time, tomorrow I am going to fill an report at launchpad, with an reference to this report. I think Sam Spilsbury should also take a look at this.

*grin* See if you can convince him to make unity/compiz valgrind clean. ;-)

Hey Chris,

We're actually generating the pixmap used to display the window border out of process in the window decorator and then binding that using glXCreatePixmap () , glBindTexture (GL_TEXTURE_2D, texName) and glXBindTexImageEXT () with GL_TEXTURE_2D_EXT as the target.

From what I can tell in the code there, it seems like we have a workaround for drivers that don't advertise the available texture targets in their fbconfigs by setting the target to the opposite of what the driver says isn't available (eg GL_TEXTURE_RECTANGLE_EXT for a missing GL_TEXTURE_2D_EXT and GL_TEXTURE_2D_BIT_EXT for a missing GL_TEXTURE_RECTANGLE_BIT_EXT

If the borders are white from time to time, it could be that the width and height of the pixmap are powers of two at this time (keeping in mind that the generated pixmap size for the window is not the same size as the window itself, since the pixmap is deformed using a simple quad-stretch algorithm). In that case, we would be forcing the use of GL_TEXTURE_2D_EXT (since it is faster) and not GL_TEXTURE_RECTANGLE_EXT

Perhaps it would be of use for me to provide a patch for compiz for the reporter to test with GL_TEXTURE_RECTANGLE_EXT always in use for tfp operations and to print any GL errors that happen when we attempt to bind textures?

Cheers,

(In reply to comment #9)
> *grin* See if you can convince him to make unity/compiz valgrind clean. ;-)

That's the plan, when I get time to do it :) There are certain sections in the code that are throwing valgrind warnings for reasons that I haven't been able to determine yet, but they aren't rendering related.

I noticed that rendering was affected by running unity under valgrind. That may or may not be relevant.

(In reply to comment #12)
> I noticed that rendering was affected by running unity under valgrind. That may
> or may not be relevant.

It could be timing related. Anyways, I've talked to Achim about running a patch that defaults to GL_TEXTURE_RECTANGLE_EXT for binding (this is slower but it might give more insight) and also printing gl errors every single time a bind fails.

Right... This is starting to look suspiciously like mesa caching region names past the lifetime of that name. I think there is a correlation between 'Region for name %d already exists, but is not compatible.' and the appearance of the white border.

The 'Region for name...' is not the issue behind the white borders, afaict. The white borders happen even without that warning being issued. It's a genuine disagreement between sna and mesa, so I'll fix it at some point, but for now it is a dead end.

Sam Spilsbury send me two patches that I tried:

1. force_no_tfp.patch
2. force_rectangle_textures.patch

Both patches were applied against compiz git.
There was no Unity running only gnome-panel and gtk-window-decorator.

As it seems right now there is no obvious error in compiz.

Created attachment 49460 [details] [review]
Force no texture from pixmap

Created attachment 49461 [details] [review]
Force rectangle textures

*** Bug 39326 has been marked as a duplicate of this bug. ***

I give in. I can't get the behaviour I want, so tweak the heuristic...

commit 12070b8eb1e98cb158802fff3e59f906b1547877
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Sep 22 12:18:26 2011 +0100

    sna/dri: Play with marking bo reusable
    
    Since we have no recycling of wc pages in the kernel, we try hard to
    recycle buffers in userspace to avoid GTT thrashing. This requires
    co-operation between DRI clients and X, which is sadly lacking and so we
    need to discard any buffer given out to a client after it is finished.
    We cheat slightly for page-flips and access to the scanout.
    
    A further compromise.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=38732
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I found no better short-term solution:

commit 78d4e99fc916e6477edb01c6f24b69ad73adc552
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Nov 15 11:06:04 2011 +0000

    sna: And keep unity happy
    
    Rewrite the DRI layer to avoid the various bugs and shortcomings of the
    Xserver and interfacing with mesa.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38732
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39044
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>