Delaying texture copy creates flicker

[mihe]

... when not using CefBrowserHost::SendExternalBeginFrame and instead just relying on CEF to do the frame requests itself.

Basically, the implementation of OnAcceleratedPaint in our own application can sometimes take a while to actually perform the copy from the shared texture. It seems like that delay sometimes causes a blank texture to be copied, resulting in it flickering on and off at random times.

We managed to reproduce the issue with the HUD view in this branch of cefmixer, using .\cefmixer.exe --sleep=30 about:blank. The branch just removes the usage of SendExternalBeginFrame and puts a Sleep(...) in FrameBuffer::on_paint to simulate some arbitrary delay between OnAcceleratedPaint being called and the frame actually getting copied. You might have to tweak the length of the sleep in order to reproduce it yourself though.

Here's a small clip showing what it looks like.

Having the application's own vsync on or off doesn't seem to matter, but toggling it can sometimes force the issue to appear.

[wesselsga]

I've also been fighting a flickering issue on older AMD-based hardware. I ended up modifying the pull request so that when not using keyed mutexes ... Chromium will use a stand-alone texture (non-render target) that is marked as shared and the FBO will be bound to a non-shared texture. Then CopyResource is used in Chromium to update the shared texture.

I also updated cefmixer to not use keyed mutexes currently. I was able to reproduce the issue using your sleep option and I believe it should now work if you disable keyed mutexes with:

window_info.shared_texture_sync_key = uint64_t(-1);

When using this option, I didn't see any flickering using CEF's timing or SendExternalBeginFrame.

I think the keyed mutex option should be modified to lock/unlock in sequence vs. always using key 0. That is acquire(0) -> release(1) -> acquire(1) -> release(0) to have Chromium and the application access the mutex in sequence ... but I have been unsuccessful in getting this working yet.

For our commercial application, I'm simply using the non-keyed mutex path.

[mihe]

For what it's worth, we're seeing this issue on both AMD RX 580 and Nvidia GTX 970. I've also seen the issue happen with SendExternalBeginFrame in our own application, but unfortunately I can't reproduce that in cefmixer.

I'll pull down your latest changes and give the non-keyed mutex path a try.

[mihe]

Can confirm that disabling keyed mutex texture fixed the flickering issue. Thanks!