Bug: pixmap can't be bound to texture ...

[RYX]

I was finally able to locate the source for that very annoying bug some people may know. Maybe it is related to the NVIDIA-drivers, but I can reproduce it now:

1. run compiz from a terminal
2. Open a gtk-program that allows you to select something (like gedit)
3. select something and drag the selection

Now the terminal should repeatedly output something like this:compiz: pixmap 0x2200ce8 can't be bound to texture
compiz: Couldn't bind redirected window 0xe03698 to texture


This problem also happens with beryl, so maybe someone can confirm it? Or is it a known problem of the nvidia-drivers?

:)

[mikedee]

As far as I know this happens with sometimes and that it isn't really a big problem, more of a warning. If you do not have any other problems associated with it, I think is is not anything to worry about.

[RYX]

It is causing an infinite loop which is repeatedly outputting that error, maybe only to /dev/null if not started from terminal, but still it has to be considered as a deadloop ... and I think that shouldn't be just ignored. It disappears when you close the app by which it was caused, but if caused within e.g. nautilus it runs forever without being noticed.

[mikedee]

Here is the code from window.c which outputs this error. As you can see it doesnt seem to be a fatal error, it just prints the error message and then carries on anyway.

if (!bindPixmapToTexture (w->screen, w->texture, w->pixmap,
w->width, w->height,
w->attrib.depth))
{
fprintf (stderr, "%s: Couldn't bind redirected window 0x%x to "
"texture\n", programName, (int) w->id);
}

setWindowMatrix (w);

I do not think it is entering a loop, it is just outputing the message on every screen paint (I think - not sure on that).

If you like you can start compiz like this which I think will redirect these errors to /dev/null

compiz --replace gconf 2>&1 > /dev/null

This is obviously just hiding the evidence though... Maybe someone else can shed some light on exactly what would cause this error, and maybe a solution.

[RYX]

I will avoid posting 10.000 lines continuous console-output to prove that it really loops ... :)

Thanks for finding the source. And you're right, it doesn't look like a loop - makes it even more strange. Are you able to reproduce it? I am really interested if you have the same problem (we have the same graphics chip, right?) ... otherwise - which driver are you using? Nvdia's 9629 or the newer beta-driver?

I agree that it is not a critical bug, but I know it's there and that bugs me ... so I want to hunt it down.

:)

[mikedee]

I cannot reproduce it because I do not have gedit and I use gentoo so getting it is 4 hours compiling away :D

Looking more into the code, it looks like a window is being created which is not rectangular. This is probably why it ends up not being able to bind it to a pixmap which is always rectangular.

From texture.c

(*screen->queryDrawable) (screen->display->display,
texture->pixmap,
GLX_TEXTURE_TARGET_EXT,
&target);
switch (target) {
case GLX_TEXTURE_2D_EXT:
blah blah...
break;
case GLX_TEXTURE_RECTANGLE_EXT:
blah blah...
break;
default:
fprintf (stderr, "%s: pixmap 0x%x can't be bound to texture\n",
programName, (int) pixmap);

I do not know what GLX_TEXTURE_2D_EXT or GLX_TEXTURE_RECTANGLE_EXT are exactly, but your dnd window (most likely) doesnt produce a texture which is either one of them :)

[RYX]

Gedit was only an example, it happens with any app in which you can select something and then drag the selection (firefox, nautilus, scite, ...) ... I have no KDE-apps to test, but maybe its a gtk-only behaviour ...(If you try it with firefox you have to close all instances to stop the bug)

I think the selection (a selected text or element) is no visible window at all so it should be handled differently by compiz. But as it looks - it doesn't get handled at all ... and maybe resides somewhere in some property/attrib and then causes the loop by permanently being non-rectangular and unhandled? Just a thought.