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
_______________________________________________
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
