question about what thread calls OnPaint

[sepehrl]

Hello, I have a little confusion about where exactly OnPaint is being called. In versions prior to 2494 (current dev branch), I used to have a mutex in my CEF renderer class and copy the buffer out of it for my UI thread but after I upgraded to 2494 I noticed OnPaint is always being called on my UI thread and once my UI update() loop tries to pull the copied buffer, it raises an exception because the mutex is already locked by the same thread.

So bottom line, my question is who calls the OnPaint and where? docs says after I call Invalidate(), OnPaint is supposed to be called asynchronously but that is not happening in my case.

I am not actually complaining, the performance is fantastic with 2494, I no longer need to double-copy the browser buffer, I am just curious if something has changed in the architecture that I am not aware of. Thanks in advance!

I am using: CEF3 - 2494 on Windows 10

[magreenblatt]

What CEF version were you using previously? Are you using software or GPU rendering?

[sepehrl]

What CEF version were you using previously? Are you using software or GPU rendering?

2454 was the version before it (the one that calls OnPaint in a seperste thread). I am assuming by software rendering you mean launching CEF by --disable-gpu and --disable-gpu-compositing; in that case I use the software renderer.
I have not changed the passed command lines since I upgraded. I pass the above two commands and the OSR framerste switch only.

[magreenblatt]

All CEF versions should call OnPaint on the browser process UI thread. It's possible that the asynchronous nature of Invalidate has changed, though.

[sepehrl]

Thanks so much for clarification. Is there a way to reliably check for the behavior of Invalidate() during runtime beside CEF version checking and conditional compilation?

[magreenblatt]

Thanks so much for clarification. Is there a way to reliably check for the behavior of Invalidate() during runtime beside CEF version checking and conditional compilation?

If it's not asynchronous then I would consider that a bug. Feel free to add an issue for it.

[sepehrl]

It has actually a better performance in my point of view. Having a mutex and double-copying the browser buffer is now gone. I propose CEF keeps it that way!
Before this, I could not go beyond 1920x1080 and now, because double buffering is gone I can resize my browser up to 4k resolutions and still running at 60fps.
I am now able to directly feed the OnPaint buffer into an OpenGL texture without copying it which is much faster.

[magreenblatt]

It has actually a better performance in my point of view. Having a mutex and double-copying the browser buffer is now gone. I propose CEF keeps it that way!
Before this, I could not go beyond 1920x1080 and now, because double buffering is gone I can resize my browser up to 4k resolutions and still running at 60fps.
I am now able to directly feed the OnPaint buffer into an OpenGL texture without copying it which is much faster.

Please still add the bug. At a minimum the documentation needs to be fixed and a unit test added to make sure the behavior doesn't regress (assuming the behavior can be guaranteed).

[sepehrl]

Thanks! issue reported:
https://bitbucket.org/chromiumembedded/cef/issues/1722/inconsistent-behavior-between-cef-versions