Flickering when drawing background

[X512]

This is hrev53634 gcc2hybrid.

When resizing windows or moving one window on top of another, background is drawn and copied to front buffer immidiately causing flickering. Drawing background should be a part of update process and be synchronized with application redraw handler.

Proposed patch: ​https://review.haiku-os.org/c/haiku/+/2021. No obvious regressions observed for now.

[X512]

Related tickets:

• #2416
• #9986
• #9536
• #3322
• #3038

[diver]

I've tested the patch and it's awesome! :) Now I can finally enjoy flicker free Haiku experience, so yay!

The only apps so far that still flicker are WonderBrush (but it uses liblayout, so maybe not related) and Genesis Commander (possibly custom widgets).

So far I haven't noticed any regressions so +1 from me to merging it.

[X512]

This fix is also allow to remove workarounds to reduce flickering like SetViewColor(B_TRANSPARENT_COLOR) or custom double buffering.

[X512]

I do not see any flickering in Genesis Commander.

[diver]

Odd, I can clearly see them easily...

[diver]

BTW, could you please take a look at #4335 while you're at it? :)

[X512]

Genesis Commander flickering is observed on slow machine (VirtualBox). ​​https://review.haiku-os.org/c/haiku/+/2021 seems not completely solves problem.

[diver]

Interestingly, every control flickers except for menubar, popup menus and scrollbars. Maybe controls use custom double buffering like you mentioned before?

[X512]

Replying to diver:

Interestingly, every control flickers except for menubar, popup menus and scrollbars. Maybe controls use custom double buffering like you mentioned before?

Some controls don't flicker because background is not erased by app_server for them or backbuffer was flushed after drawing them for some reason. Haiku use global screen backbuffer. Flickering is caused by improper backbuffer flushing. Backbuffer should be flushed when all drawing is done, but sometimes it is flushed after only background is drawn and this issue is about it.

[X512]

I debugged Genesis Commander on VirtualBox and found that ​https://xref.landonf.org/source/xref/haiku/src/kits/interface/Window.cpp#1221 fails sometimes with B_BAD_VALUE and window will not draw anything.

[X512]

For some reason data sent after ​https://xref.landonf.org/source/xref/haiku/src/servers/app/Window.cpp#1945 is not received sometimes. That cause read fail on libbe.so side.

[X512]

Genesis Commander case fixed in ​https://review.haiku-os.org/c/haiku/+/2099.

Issue still present in WebPositive.

[X512]

Sorry, WebPositive is also fixed. gcc4+ version of libbe.so was not updated.

[diver]

Great! I'm gonna test it now. Have you looked into WinderBrush? Maybe it's also fixed now?

[diver]

Replying to X512:

Genesis Commander case fixed in ​https://review.haiku-os.org/c/haiku/+/2099.

Issue still present in WebPositive.

Confirmed that both WonderBrush and Genesis Commander flickering is fixed with this patch. It also fixes #8895 (tested) and possibly #8525. Very cool! :P

[diver]

Odd, after starting many apps flickering is back in WonderBrush, WebPositive and #8895.

[X512]

In my case 2 bottom lists are flickering in WonderBrush. They flicker even if separator between lists is dragging. Probably WonderBrush is doing something wrong like drawing outside of update session.

[X512]

Replying to diver:

Odd, after starting many apps flickering is back in WonderBrush, WebPositive and #8895.

Was something changed in flickering? Does menu artifacts persists after stopping moving/resizing?

Note that 2 patches (​https://review.haiku-os.org/c/haiku/+/2021, ​https://review.haiku-os.org/c/haiku/+/2099) should be applied.

[diver]

Replying to X512:

In my case 2 bottom lists are flickering in WonderBrush. They flicker even if separator between lists is dragging.

I see that too.

Was something changed in flickering? Does menu artifacts persists after stopping moving/resizing?

Note that 2 patches (​​https://review.haiku-os.org/c/haiku/+/2021, ​​https://review.haiku-os.org/c/haiku/+/2099) should be applied.

Yes, both patches are applied. I can't reproduce flickering in Genesis Commander/WonderBrush/WebPositive right after reboot. But after starting all of the apps in Deskbar->Applications they are back in said apps.

[X512]

WonderBrush flicker may be caused by problems in liblayout. Is source of liblayout available?

[diver]

Interestingly, when mentioned apps (including WonderBrush) start to flicker reopening them fixes that. PM me on telegram (@diversys) if you still need liblayout sources.

[X512]

What platform is used (x86, x86_64)? Does multiple CPU cores used?

[diver]

This is x86_64 in VMware Fusion with 2 processor cores.

[diver]

Ok, it seems that I found a way to reproduce it.

All of the mentioned apps do not flicker when started via ​QuickLaunch!
However, when started from Tracker they do flicker and this is how I've been launching them starting from comment:23.

[diver]

Ouch! Finally realised what was going on. I had libbe.so with one of your previous patches in non-packaged/lib. With this out of the way there is no flickering at all! Sorry for the confusion.

So, +1 for both fixes, no regressions observed so far. \o/

[diver]

Finally fixed in hrev53711.

[diver]

Flickering can still be observed in Genesis commander and many other apps by resizing its window using left border. You need to hold middle mouse button above left border to enable resize mode.

[X512]

Flickering confirmed, but with right mouse button. Midlle mouse button has no effect. Observed only on slow machine. This resizing mode was not present in BeOS and was introduced in Haiku recently. Maybe it introduce new issues.

[X512]

It seems that window move sometimes cause backbuffer flush.

[X512]

Created new ticket #15631 for that.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone