Blinking background under the mouse cursor

[miqlas]

Since the recent "blinking" changes from X547 or X512 the background started to blink under the mouse cursor in Koder during text selection if a compilation runs in the background.

This is Haiku shredder 1 hrev53732 Jan 19 2020 08:40:01 x86_64 x86_64 Haiku

See the screenshot in the attachments.

[miqlas]

Mouse cursor leaves tracelines in ActivityMonitor

[miqlas]

Mouse cursor leaves tracelines in ActivityMonitor

[waddlesplash]

X512, can you take a look?

[X512]

Artifacts caused by moving cursor are present in Haiku for a long time since introducing screen double buffer. It caused by flushing back buffer at cursor location when it is not ready. There is no easy fix, but I have some ideas such as make additional buffer for every overlay layer objects (cursor and drag&drop contents).

Views that use backbuffer BBitmap and SetViewColor(B_TRANSPARENT_COLOR) like Koder and Qt applications were not affected by this, but after hrev53713 it are affected. Before hrev53713 only bitmap was painted on update so no flickering even if backbuffer was flushed early, but now background and then bitmap is painted. Fixing this require introducing some new API to distinguish transparent view and disabling background drawing.

[X512]

In ​https://review.haiku-os.org/c/haiku/+/2275 B_TRANSPARENT_BACKGROUND flag is implemented. If this flag is not set, behavior is same as in BeOS. If flag is set, view become transparent, views under it are painted before.

This patch fixes flickering under cursor in Koder and other applications that use SetViewColor(B_TRANSPARENT_COLOR) and DrawBitmap.

[waddlesplash]

but now background and then bitmap is painted.

I guess I'm confused as to why this is necessary (though app_server is not my forte to say the least.) I guess we are painting the parent view's background? Is there no other way to avoid that overdraw here? Is there no other way to decide that we do/do not want to paint the background besides adding a flag?

[X512]

Replying to waddlesplash:

Is there no other way to avoid that overdraw here?

Currently there are no way to avoid overdraw. If background is set, it will be painted, if B_TRANSPARENT_COLOR is set, parent view will be painted before. In BeOS SetViewColor(B_TRANSPARENT_COLOR) disable background painting and NOT draw parent view before. This behavior was changed in hrev53713 to support transparent views. In ​https://review.haiku-os.org/c/haiku/+/2275 I restored BeOS behavior if flag is not set.

[waddlesplash]

In the case of SetViewBitmap, could we skip drawing the background altogether if possible? Would that help with Koder (I guess it probably does not use SetViewBitmap, but maybe it could?)

[pulkomandy]

Yes, but SetViewBitmap isn't properly implemented IIRC. Axeld has a very old branch with work on fixing this (possibly not even migrated from SVN?)

It would also allow to handle the desktop wallpaper properly, so it doesn't disappear when Tracker exits, I think.

[pulkomandy]

Also you could do SetViewBitmap with a bitmap having an alpha channel, and still expect the parent view to draw, maybe?

[X512]

Replying to pulkomandy:

Yes, but SetViewBitmap isn't properly implemented IIRC. Axeld has a very old branch with work on fixing this (possibly not even migrated from SVN?)

Any details?

[pulkomandy]

I guess here? ​https://github.com/axeld/haiku/tree/background

[waddlesplash]

AFAICT that is entirely about Desktop background drawing, I don't see any View related changes at all.