Moving Firefox window around flickers window content

[diversys]

As in title. However, it doesn't seem to happen in Gnome Web

[X547]

It is technically Haiku bug because back buffer is flushed before drawing is completed when dragging window of then moving mouse pointer over window.

It can be avoided on wayland-server side if buffer have no alpha channel, but workaround for alpha channel will introduce significant overhead (extra BBitmap buffer and blending) and refactor (transparent BView's can't be used anymore).

So it is actually a duplicate of https://dev.haiku-os.org/ticket/15920 .

[kenz-gelsoft]

I think this is improved a lot by following changes

04eeba4...3e61d9b

756287d...3e61d9b

Menu popups tend to flicker yet, but it seems same level as GIMP.

I didn't check how firefox sets opaque region for popup windows, but as far as see its behavior I guess they don't specify opaque region for popup windows to achieve content rendered drop shadow.

I'll look into that later. (That fix will be firefox's one)

[waddlesplash]

Copying this bit of documentation from a comment I posted in #16:

However, the wl_surface state associated with this subsurface, such as the attachment of buffers and accumulation of damage, need not be linked to the parent surface's lifecycle. This is the purpose of the set_sync and set_desync requests. Subsurfaces synced with their parent surface will commit all of their state when the parent surface is committed. Desynced surfaces will manage their own commit lifecycle like any other.

Perhaps this is why the dirty state doesn't work properly for Gecko: it's using synced subsurfaces, so we need to recursively call into them? If that's the case, fixing that will allow reinstating the Invalidate of only the dirty region instead of the entire window every time.

[waddlesplash]

(Admittedly, that fix will help the "flickering under cursor" problem more than the "flickering when moving window" problem, I guess.)