-
Notifications
You must be signed in to change notification settings - Fork 166
SWT Linux Gtk - Capturing screenshots broken in 4.35 #1891
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
What happens if you call dispose() on GC after use? |
I can see the same behavior with Snippet 215 on my side as well. |
I can confirm the behavior with Snippet 215 on my system as well. Side note: on a system using Wayland the functionality does not work at all, neither with the current nor with the previous state. It always produces a blank result. Simplest solution would of course be to revert the change to |
Just a remark: The eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/graphics/GC.java Lines 473 to 491 in 74635dd
I really don't see a conceptual problem with using
At least until someone can figure out what exactly is going on, that is probably the best solution. I'll still try to extend my test cases so that any future regression will be detected as early as possible. |
Yes, thank you for the clarification. The whole functionality is not working on GTK4 or when using Wayland, no matter which version of the Image class is taken. I am not an expert in that area but since there are some other limitations on Wayland which, if I am not mistaken, have some security reasons (like positioning top-level shells), capturing the screen may be a functionality that is not allowed there anyway. |
…rm#1891 A previous change unified the Image surface initialization for blank Image instances just based on height and width. Because of the change, screen capturing using a GC on the display does only work properly when executed the first time in an application lifecycle and in specific situation, the initial properties of a GC changed (such as the text anti-aliasing behavior). Due to a lack of a better solution for now, this change reverts the unification of the Image surface initialization to the previous state. Fixes eclipse-platform#1891 This partially reverts commit 5c2611d.
I've proposed the revert as: If anyone has a better solution or would like to work on one, that would of course be highly appreciated and we can postpone merging the revert then. |
Since there was no idea for and no expression of interest for working on a different solution so far, I will merge the revert. Improving the behavior as a follow-up is of course still possible and will eventually be necessary for GTK4 anyway. |
…rm#1891 A previous change unified the Image surface initialization for blank Image instances just based on height and width. Because of the change, screen capturing using a GC on the display does only work properly when executed the first time in an application lifecycle and in specific situation, the initial properties of a GC changed (such as the text anti-aliasing behavior). Due to a lack of a better solution for now, this change reverts the unification of the Image surface initialization to the previous state. Fixes eclipse-platform#1891 This partially reverts commit 5c2611d.
Describe the bug
Captured screen images on Linux don't change after the first capture. Regardless what happens on the desktop, the image remains constant.
To Reproduce
In essence I'm using the following code to capture the image.
public Image captureScreen(int x, int y, int width, int height)
{
Display display = Display.getCurrent();
Image swtImage = new Image (display, width, height);
GC gcDisplay = new GC (display);
gcDisplay.copyArea(swtImage, x, y);
}
Expected behavior
Call the method, do something to change the desktop, call the method again to get an updated screenshot
Screenshots
implicit
Environment:
Ubuntu 24.04, 22.04, 20.04
17.0.13
Version since
Eclipse or SWT version since when the behavior is seen
4.35
Workaround (or) Additional context
The bug was apparently introduced in the change to Image.java in revision 5c2611d
Reverting just the few lines in Image.java fixes the issue!
The text was updated successfully, but these errors were encountered: