Buffer swap from another application.

The xfce4-screenshooter inserts the old area from the Gnome Disk benchmark into the image buffer. Usually shows up with small and medium windows: Terminal, KDiskMark, Thunar, but does not show up with Telegram and Firefox.

Below is an example of a screenshot of Thunar. It inserts an image of the old benchmark on top of the desktop. The size corresponds to the Thunar window.

After rebooting, the problem repeated itself. But now there is a piece of the desktop in the buffer. The xfce4-screenshooter just doesn't see the topmost layer.

Please provide steps of how to reproduce this bug and the versions you're using (distro, xfce, screenshooter, gnome disk).

Arch, Xfce 4.16, xfce4-screenshooter 1.10.0-1, gnome-disk-utility 43.0-1.

But the problem does not occur only after starting Gnome Disk. I will try to find the cause and reproduce the repetition.

I can't explain yet, but I have the same kind of behavior here (Arch, Xfce 4.16, xfce4-screenshooter 1.10.0-1)

I screenshot a region of my Terminal, and the generated screenshot is from Chromium!

Note: after a few tests, when the bug is triggered, it's always the "same" screenshot (!), but cropped to the region I selected, as if the image is kept in buffer forever!

Note: I have a laptop with a dual screen setup, when I disconnected my external screen, problem disappears

Hmm, unfortunately I can't test with a second screen right now, in the meantime, please confirm if only Region mode is affected.

Also, please check if this is reproducible with gnome-screenshot.

Region, "Active Window" and "Entire Screen" is affected. Not reproducible with other screenshot tools, but i havent tried gnome-screenshot.

Im not using a second screen, same config (xfce4-screenshooter 1.10.0-1) as above

Just tried gnome-screenshot (41.0+r25+g45f08f0-1 from Arch repositories), I can reproduce ! :o

I still cannot reproduce, I'm using Arch, xfce4-screenshooter-1.10.0-1, Xfce from git master and an external monitor (extend to the right), no luck.

Are there steps to reliably reproduce this? It would be nice to check if this is only reproducible with a second screen as well as whether disabling compositing has any effect.

Just tried gnome-screenshot (41.0+r25+g45f08f0-1 from Arch repositories), I can reproduce ! :o

I suspect this isn't a screenshooter bug, under the hood it basically gets X11's root window (gdk_get_default_root_window) and clips a pixbuf from it (gdk_pixbuf_get_from_window), meaning it could be an xorg, gdk or video driver issue (nvidia here).

Please also check if bug is reproducible with this little sample.

added 3. Need Info label

Exact same symptom here (dual or triple monitor, Manjaro, xfce4-screenshooter-1.10.0-1, intel gpu and driver).

I will test with your sample C file, with or without multi-monitors plugged in.

[Edit] just compiled the sample with gcc sample.c $(pkg-config --cflags --libs gtk+-3.0) -o sample and I run it, I got a big correct screenshot.png with my three monitors on it. If I do the same with xfce4-screenshooter, I got an old buffer (the png is completely wrong for all three monitors)

By "xfce4-screenshooter", did you mean the panel plugin?

yes

I also tested with scrot: no problem so I don’t understand…

Ok, I did some research, and if I use for instance xfce4-screenshooter -r from the command line, it works perfectly. If I do it from the Xfce4 panel plugin (libscreenshooterplugin.so) then I got a screenshot from an old buffer.

Could this be related to some refresh root window or something? When I run the binary from command line, all resources need to be created for the screenshot process to occur, similar to what sample.c does.

Perhaps some old references are kept in the panel plugin that shouldn’t. I don’t know what changed in gdk or other lib to trigger this behavior. What do you think @andreldm?

Sorry, no idea what's going on. Disabling the compositor makes any difference?

I tested that, no difference.

To reproduce with one monitor:

• Configure Xfce to have two workspaces
• Create a screenshot on first workspace using the panel plugin
• Move to second workspace
• Create a screenshot on second workspace using the panel plugin
• See that the second screenshot (window, region or fullscreen) reference what was on the first workspace

Nope, no reproducible issues for me.

Everyone else affected, can you reproduce with those steps?

Aha, I was able to reproduce when using the integrated video card (intel) but not nvidia. Weird behavior. Will investigate.

Other info: if I plug or unplug a monitor, then the screenshot for the active workspace is now correct. Something smells for gdk or cairo…

I've updated the sample to take a screenshot every two seconds saving them to /tmp, it is indeed kind of stuck at the first captured pixbuf.

For me the problem is only reproducible when a screenshot is taken more than once by the same process, i.e. screenshooter's panel plugin, also with both screenshooter and gnome-screenshot if you take a screenshot, go back and take again. gnome-screenshot also uses gdk_pixbuf_get_from_window so this isn't a surprise, I could report a bug for Gtk/Gdk but that function and its "sibling" gdk_cairo_set_source_window are removed in GTK 4, their replacement (Gtk.Widget.snapshot) is not available in GTK 3.

I tried to get a screenshot with only Xlib and cairo, all I got were corrupted images (no segfaults though, haha), then I checked how scrot takes screenshots, it uses Imlib2, I put together a similar sample using it, works perfectly.

All in all, I'm almost convinced this is a problem with Gdk when using Intel driver. I'm going to check another compositor and xf86-video-intel instead of modesetting just to be sure.

No difference using xf86-video-intel, in a Gnome on Xorg session the bug is reproducible with screenshooter but not with gnome-screenshot, quickly checking the source code I think they use the shell backend, x11 backend which relies on gdk_pixbuf_get_from_window is only a fallback.

I guess this is what I've been seeing lately, but I have a Radeon card (lspci identifies it as Radeon R7 260X/360) so I don't think the Intel driver is involved for me.

I thought maybe it happened when I enabled the amdgpu driver, but switching back to the older radeon driver doesn't seem to make any difference. (Assuming I didn't mess up along the way, which is always a possibility.)

I don't have display compositing enabled.

Could it be related to mesa which is both used by intel and radeon, but not by nvidia?

I also confirm that sample2 is working correctly in my case.

Interesting, this bug is also reproducible in a virtual box vm, so nvidia is the exception here, surprisingly the good exception for once

I'm really not in love with the idea of adding Imlib2 as a dependency just to fix this, I'll try to get a pixbuf of the root window just using xlib, if I fail so be it, Imlib2 to rescue.

mentioned in issue #93 (closed)

assigned to @andreldm

removed 3. Need Info label

Fix available at !41 (merged), please test.

Just tested this branch, and with no surprise, it works perfectly.

Thanks for testing.

@eriktorbjorn1 since you have a different hardware and @gegrby since you're the OP, if possible test that MR, with your confirmation I can merge it and cut a release ASAP.

With the caveat that I'm running the Debian (unstable) packages, I applied the patch to their sources and built the package. It seems to work fine that way. Thanks!

@andreldm There is no way to test, so I will check as soon as the package is updated.

mentioned in commit 810784f2