[compiz] White Boarders in AIGLX on non-decorated window types
vasek.potocek at post.cz
Wed Apr 18 10:25:45 PDT 2007
>> 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?
More information about the compiz