-
Notifications
You must be signed in to change notification settings - Fork 152
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
Cursor and overlay elements overwrite primary plane in RenderFrameResult::blit_frame_result
#1378
Comments
cc @cmeissl |
Thanks for reporting this issue!
Yes,
@Ottatop can you try to verify this by disabling the |
Can confirm that disabling |
Thanks for testing, can you try if #1381 fixes the issue while keeping |
Yep, it does fix the issue! |
Background: I'm implementing wlr-screencopy by blitting the frame result to a
GlesRenderbuffer
and giving the bytes to the shm buffer.When doing the blit, any element on the cursor or overlay planes completely overwrites pixels underneath it, regardless of its transparency. Below is a sample screencopy (screenshotted from feh to show transparency):
I'd expect the background behind the Alacritty on the overlay plane to still be there, but it's been overwritten to just the terminal's pixels. Similarly there's a transparent hole around the cursor for the same reason.
Disabling the overlay and cursor planes fixes the problem. Digging into the method, I think it's because elements on those planes are being
RenderElement::draw
n into the target buffer after blitting the primary plane in. Is that supposed to overwrite pixels already in the buffer even if what's getting drawn in has transparency?The text was updated successfully, but these errors were encountered: