[compiz] White Boarders in AIGLX on non-decorated window types

[Vasek Potocek]

>> Oops, I haven't finished my e-mail... The reason why I posted just another workaround is that I consider it "less 
>> workaround" than the former fix (supposing this really was the same problem) and that it helps in more situations (like 
>> in GTK+ drag-drop, RYX said he had problems with this). But it's really hacky, it should apply depending on whether the 
>> described circumstances really happen and so, but as I said, it's temporary and only for the interested. I use it in my 
>> local clone and I actually haven't had many reasons to make it cleaner.
> 
> OK, so a bug in the nvidia driver is causing this problem then. If the
> change you had in your previous mail is working as a way to avoid the
> problem, I'll be able to modify the code and make it work without having
> it do anything wrong.
> 
> - David

I honestly can't say for sure, it works reliably for the p-o-t pixmaps generally, but I didn't have the particular 
problem with the decoration. My "normal" windows sized 32x32 or 128x128 or even 8x64 or anything like this were painted 
white (accompanied by a flood of "pixmap ... can't be bound to texture"). Sorry for splitting my mail so stupidly, this 
is how it started:

> I haven't seen this problem nor searched the internet for more info on this topic, so I'm sorry if I'm answering too
 > impetuously. But talking about restricting texture sizes, this looks to me similar to a problem of some NVIDIA cards
 > (say: of my one) I have examined some time ago: when the fbConfig doesn't have its GLX_TEXTURE_2D_BIT_EXT set in
 > GLX_BIND_TO_TEXTURE_TARGETS_EXT, the power-of-two textures cause a BadMatch error in glXCreatePixmap instead of being
> treated as rectangle ones as the GLX_EXT_tfp specification states. Couldn't this be related?


- Vasek