Excessive flickering with master haikuwebkit

[madmax]

There's noticeable flickering with ​current development HEAD. A very annoying example is the color animation in ​https://browserbench.org/MotionMark1.2/, although can be seen to some extent in github, gerrit and other sites. Reverting ​e85f96e292 fixes it for me, but given the commit message, I'm not sure that's the correct solution?

[nephele]

IIRC there was going to be some work to lock bitmaps to prevent this that didn't pan out.

Personally I wouöd much prefer slower rendering to flickering anyhow.

[pulkomandy]

Personally I prefer it faster but flickering so I left it that way. It's a step in the right direction but to stop the flicker it would need support for locking bitmaps to tell app_server to not use them while they are being redrawn, I discussed this with waddlesplash and he thinks it's not possible.

With the old code from before that commit:

• webkit draws into an offscreen bitmap
• This is sent to app_server through draw_bitmap when it's ready, and copied to the backbuffer, possibly this happens several times without any actual screen refresh
• Then the backbuffer is copied to the frontbuffer

Surely there has to be a more efficient way to do this…

The change replaces the DrawBitmap with a SetViewBitmap, which lets app_server control when it copies data from the offscreen bitmap to the backbuffer (it should do it just as needed before copying to the frontbuffer). But now it can do so while the buffer is not drawn yet, and this results in the flickering.

If several people find this annoying let's just revert the change and wait for someone to have a better solution.

[waddlesplash]

Yes, it's not really possible. I thought I typed up an explanation on some ticket but I don't know where that is now. If I recall correctly, there is not really a way to obtain the window object from the bitmap object at draw time without running into lock-order-inversion or accessing things we can't.

I think there a few changes which can be made to improve things:

• Modify SetOffscreenViewClean to not do immediate drawing but to just call Invalidate (as in the original commit) -- I suspect this will make a large difference by itself (why is there an "immediate" option anyway?)

• Move the creation of the GraphicsContextHaiku inside the the if (again as in the original commit)

• Try using DrawBitmapAsync instead of DrawBitmap. This may also cause flickering as it will merely be sure the bitmap is unlocked before drawing begins, but it could also not.

Finally there is the more drastic solution of introducing yet another bitmap as the view bitmap and copying to that when there is something to show. I don't know how good an idea that is however.

[X512]

I recommend to switch back to DrawBitmap for now like I did for Wayland. SetViewBitmap also have a major problem that it automatically invalidates a view and do not support passing invalidate region.

[SamuraiCrow]

Is this really a problem with HaikuWebkit? It sounds more like a problem with the graphics rendering pipeline.

[nephele]

Yes it is, why would a haikuwebkit specific flickering issue not be a haikuwebkit issue?

[SamuraiCrow]

Usually screen and bitmap locking routines are supplied by the operating system itself. That's why. If the graphics drivers don't supply a page-flipping API to hide the work that's going on during an update to screen data, where does it come from?

[X512]

Replying to SamuraiCrow:

Is this really a problem with HaikuWebkit? It sounds more like a problem with the graphics rendering pipeline.

BView::SetViewBitmap() API is not ready for this usage yet so currently BView::DrawBitmap() should be used. BView::SetViewBitmap() can be introduced later when it woild be ready on app_server side for this usage, but now commit ​https://github.com/haiku/haikuwebkit/commit/e85f96e292 should be reverted.

[bipolar]

Just another user point of view:

On my machine and VMs, the flickering is pretty bad, sadly (just using Github and this Trac instance). I would prefer it slower but less visually stroboscopic :-D

[humdinger]

I would prefer it slower but less visually stroboscopic :-D

I agree. On some sites you get a flicker with every key stroke.

Even more unnerving, however, is that almost every site gets stuck loading and links have to be re-clicked, or re-opened in another tab. Sometime several times. See #18122.

[pulkomandy]

Fixed in ​https://github.com/haiku/haikuwebkit/pull/19 which will be part of haikuwebkit 1.9.3.