GNOME Bugzilla – Bug 696094
cogl_texture_get_data returns garbage for TFP textures
Last modified: 2015-01-11 15:22:55 UTC
We use cogl_texture_get_data on TFP textures to create window screenshots in gnome-shell but for some reason when using the proprietary nvidia driver the resulting data is garbage. I am not sure whether this is a driver or cogl bug. Reading back other textures works fine, we had a similar issues in the past see bug 669368 and bug 673137 there are not the same but we seem to need another code path there for a reason maybe it broke due to other changes.
Jon is seeing this using the intel driver as well.
I can't replicate this issue on my Intel Sandybridge laptop at least. When grabbing the data for the window, Mutter will create a subtexture of a smaller region of the window and instead try to get the data for that. This will make it call texture_get_cb with a subregion of the texture. There is no GL function to read a subregion of the texture, so Cogl will try to work around this in one of two ways. Either it will create a temporary framebuffer object and call glReadPixels on that, or it will just read all of the data into a temporary buffer and copy that out. When grabbing the texture, Mutter will also read back the texture data for the mask texture which I guess contains the window's shape. This is an alpha-component texture. I vaguely remember that creating an alpha-component framebuffer doesn't work on some hardware (I think it was nVidia) so it might be falling back to the temporary buffer in that case. Creating a framebuffer to a TFP texture or an alpha texture seems like quite a corner case of the driver, so it doesn't seem totally unlikely that the driver doesn't like this. Perhaps we could try working around this by always reading back all of the texture data. I'm about to attach a patch for Mutter which would do this. It would be good to try this, even if just to rule out issues with FBOs.
Created attachment 241295 [details] [review] Use cairo not cogl for subsurface in meta_shaped_texture_get_image Instead of using cogl_texture_new_from_sub_texture to create a sub region of the source texture, it now just grabs all of the data from the texture into a larger cairo surface and then creates a second image surface which points into a sub region of the first surface. Using Cogl to create the sub texture means it would end up trying to read a sub-region of a GL texture. This is either implemented by creating a temporary frame buffer object and then using glReadPixels, or by reading the whole texture into a temporary buffer and then copying it again into a second smaller buffer. Using a framebuffer with a TFP texture or an alpha-only texture seems like a likely candidate to cause problems and may be related to bug 696094 which is showing corruption. Using a full size buffer in Mutter instead would work around any problems using glReadPixels. If Cogl is using the second option where it will create its own temporary buffer, then this approach will be faster because it will remove one copy.
Review of attachment 241295 [details] [review]: As I told you on IRC I have tried to skip this code path while debugging so I don't expect this to work. (maybe you somehow missed that), I did just test with this patch and it did not help.
It seems I'm having a similar issue on Ironlake here. It only happens when the window is wider than the screen itself. Try taking a window screenshot of a window larger than the screen, and you should see it for yourself. The patch fixes the issue, by the way.
*** Bug 699496 has been marked as a duplicate of this bug. ***
OK seems like the NVIDIA related one is indeed a driver bug: https://devtalk.nvidia.com/default/topic/526615/linux/gnome-screenshot-creates-garbled-window-screenshots/post/3843415/#3843415 "Sorry for the very slow update. We've identified the problem and it should be fixed in a future release. "
This has already been fixed: https://devtalk.nvidia.com/default/topic/526615/linux/gnome-screenshot-creates-garbled-window-screenshots/post/3992592/#3992592