Page MenuHomePhabricator

Enabling "tear free updates (VSynced)" creates strange artifacts with "scrot -s"
Closed, InvalidPublic

Description

E23 (0.23.99.0) on Elive 3.8.2 amd64 Beta on multiple machines.

When enabling "tear free updates (VSynced)" in the settings manager, composite settings, taking a screenshot of the region with "scrot -s" leaves strange artifacts when dragging the mouse.
Thus:
https://forum.elivelinux.org/uploads/default/original/2X/4/48397bbb30f46e57801971b720029d1effcb0625.png
Disabling it makes it go waway:
https://forum.elivelinux.org/uploads/default/original/2X/6/68ca901799d1c17affb2ebc6a1692da867d6c029.png

triantares updated the task description. (Show Details)Jan 10 2020, 1:27 AM
triantares updated the task description. (Show Details)Jan 10 2020, 1:30 AM
raster closed this task as Invalid.Jan 13 2020, 12:14 PM

Scrot issue. It draws a selection box. To do this it draws to root window with xor pattern and "include inferiors" thus basically scribbling all over the screen however it likes with no respect for the fact the compositor has placed a window above all others in the screensaver overlay layer. Thus it's scribbling all over where the compositor draws. This was fine to do in the days before compositing. It stopped being fine once you had compositors drawing the screen. What you have is simply a race condition where the xserver switches from using copies to buffer exchanges for displaying the screen buffer. that means with copies, the xserver COPIES the image from the gl backbuffer to the screen - thus overdrawing anything scrot managed to scribble. when it goes to swapping, the xserver will SWAP buffers. that means what buffer is displays is a pointer. "display buffer A", then switch to "dis[play buffer B" and basically the pointer is swapped. the memory that USED to be displayed on the screen now is recycled for a new backbuffer to draw on. evas (e) takes advantage of this with the buffer age extension in gl to know how old the buffer is and only draw the areas that updated.

so basically... "scrot problem". if some x client is going to turn off all the clipping and handling and just scribble wherever it wants, then it is the job of that client to clean it up and do it in a way that doesn't get screwed. i can explain how this might be possible in many possible ways and what to do, but perhaps the best thing to do is just not to use scrot and instead use e's screenshotter that doesn't scribble on the screen, and even better the brand new one that lets you crop the image right after it was shot and zoom in and out to do it as well as draw diagrams, arrows, text notations etc. on it before saving or uploading. it behaves nicely. :)

Thanks for the amazing explanation!

I reported (and linked to here) the scrot bug to its actual source code place (if im not wrong): https://github.com/resurrecting-open-source-projects/scrot/issues/36