Cursor and overlay elements overwrite primary plane in RenderFrameResult::blit_frame_result

[Ottatop]

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::drawn 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?

[Drakulix]

cc @cmeissl

[cmeissl]

Thanks for reporting this issue!

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::drawn 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?

Yes, RenderElement::draw is used to composite elements placed on drm planes into the bound buffer to align it with what drm would do during scan-out. For doing that more efficiently the blit_frame_result function uses glBlitFramebuffer for blitting the already composited. The blit_from/blit_to functions are optional and not part of the Frame Trait used for drawing. This is the reason why the function splits rendering into 3 stages, clear, blit and draw the overlay elements. Using the default capabilites for the GlesRenderer might enable color transformations which currently requires the use of a shadow buffer. My guess is that we fail to keep the content we already have drawn in this case.

blit_from does directly blit to the backing buffer and does not use the shadow buffer. But even if it did GlesRenderer::render would clear the shadow buffer anyway. Also GlesFrame::finish disables blending before blitting the shadow buffer. So it seems that it is currently not possible to render in multiple passes in case a shadow buffer is active.

@Ottatop can you try to verify this by disabling the Capability::ColorTransformations? This should be possible by using GlesRenderer::with_capabilites and in case you use the multi gpu backend by using a factory function.

[Ottatop]

Can confirm that disabling ColorTransformations works around that problem.

[cmeissl]

Thanks for testing, can you try if #1381 fixes the issue while keeping ColorTansformations active?

[Ottatop]

Yep, it does fix the issue!