Browser view doesn't work when embedded in a window using `WS_EX_COMPOSITED` under Windows

[vadz]

If a window using WS_EX_COMPOSITED is passed to CefWindowInfo::SetAsChild(), the browser window doesn't work correctly, i.e. it doesn't repaint properly nor even dispatches some other events resulting in life-time-related problems (e.g. callbacks not being called) all of which disappear if WS_EX_COMPOSITED is removed. Of course, removing it results in flicker in the other controls that are children of the same top level window as the browser, so this is not ideal.

Reproducing this problem in cefsimple would require writing a bit of Windows-specific code, but I could do it if it could be useful, i.e. if there is any chance of this limitation being lifted.

[magreenblatt]

What OS and CEF version? Do the other controls have WS_CLIPCHILDREN / WS_CLIPSIBLINGS style?

[vadz]

What OS and CEF version?

Tested under Windows 10.0.19044.3208 with the latest CEF from Spotify page.

Sorry for forgetting to mention this.

Do the other controls have WS_CLIPCHILDREN / WS_CLIPSIBLINGS style?

The parent window has WS_CLIPCHILDREN (as well as WS_EX_COMPOSITED in the extended style) and its siblings (only one, a window containing a toolbar in it) have the same style. I'm not sure if WS_CLIPSIBLINGS can change anything here, but I could try it.

[dmitry-azaraev]

I'm don't think what WS_EX_COMPOSITED can provide any benefits in chromium rendering, as well as it can't provide any sensible benefits in dwm-enabled systems (because they always composited). Chromium actually never use "normal" rendering in normal sense: double buffering for what? Composition of what? Chromium already do it in own mechanisms, without requiring any assist from this (in fact - obsolete) flag.

So, imo, good question: what problem you trying to resolve with this flag?

[vadz]

I don't especially want to use WS_EX_COMPOSITED with Chromium itself, but it is used by default by all the other windows in the application/framework and while this can be turned off, doing this turns it off for all children of the same top-level window as IME you can't have windows using WS_EX_COMPOSITED and not using it in the same window (I could be wrong, I admit I don't fully understand how does WS_EX_COMPOSITED work) and these other windows do benefit from double buffering, especially if they are native controls like e.g. the toolbar used in the example where I'm testing this.

[dmitry-azaraev]

@vadz in modern world no-one can benefit in double-buffering. DWM literally allocate texture for every window and composite your desktop. E.g. no application draw near to plysical device at all. This is why everything smooth, even while app dod not do special actions: all of them always write to backbuffer which eventually become visible. (This is hardly different from windows classics.)

[vadz]

Sorry, but no, this is not the case, there is pretty noticeable difference when using WS_EX_COMPOSITED and not using it and drawing directly on the HDC in WM_PAINT without doing any double buffering on your own. And while it's always possible to double buffer everything the application draws itself, this is not the case for the native controls which still flicker without composition but not with it.