WPF - blank display and resize glitches/tearing

[mitchcapper]

• What version of the product are you using? Cefsharp 77, although repro's in cefclient so clearly an upstream issue. --disable-gpu-compositing fixes it (although clearly disables compositing).

--off-screen-rendering-enabled on the cefclient causes it to happen.

Chrome/77.0.3865.90
Windows NT 10.0.18362
VENDOR = 0x8086 [Google Inc.], DEVICE= 0x5917 [ANGLE (Intel(R)
UHD Graphics 620 Direct3D11 vs_5_0 ps_5_0)] ACTIVE
ANGLE (Intel(R) UHD Graphics 620 Direct3D11 vs_5_0 ps_5_0)
cef_binary_77.1.11+g1687a63+chromium-77.0.3865.90_windows64_client

The page is working (context menu works, and save as PDF etc) will show what it displays. Just white screen itself.

Will work to get an upstream bug filed.

[mitchcapper]

Tested a few more machines. An nvidia GPU didn't seem to have an issue but other intel drivers did.
I found that while --disable-gpu-compositing fixes it (which leaves Rasterization: Hardware accelerated
and Compositing: Software only. Hardware acceleration disabled,WebGL/WebGL2: Hardware accelerated but at reduced performance, )
I also found --disable-gpu-rasterization fixes it (leaving: Compositing: Hardware accelerated, Rasterization: Software only. Hardware acceleration disabled, WebGL/WebGL2: Hardware accelerated).

Some older intel chipsets refuse to work at all with --off-screen-rendering-enabled (blank display like this so page there just not rendered). This is even with --disable-gpu this goes back to at least v69 however so is not new. It does work with --enable-gpu (just without the offscreen rendering flag). There is a bug report talking about rasterization issues on some gpus:
http://crbug.com/643850 however I seem unable to access details of it.

These chipsets will give an error sometimes of:
VENDOR = 0x8086 [Google Inc.], DEVICE= 0x0102 [ANGLE (Intel(R) HD Graphics Direct3D9Ex vs_3_0 ps_3_0)] ACTIVE
[1007/094549.016:ERROR:gl_surface_egl.cc(612)] EGL Driver message (Error) eglQueryDeviceAttribEXT: Bad attribute.

Some intel gpus did work:
VENDOR = 0x8086 [Google Inc.], DEVICE= 0x22b0 [ANGLE (Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0)] ACTIVE
ANGLE (Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0)

VENDOR = 0x8086 [Google Inc.], DEVICE= 0x191d [ANGLE (Intel(R) HD Graphics P530 Direct3D11 vs_5_0 ps_5_0)] ACTIVE
ANGLE (Intel(R) HD Graphics P530 Direct3D11 vs_5_0 ps_5_0)

Will gather a few more test cases and reports before submitting upstream.

[mitchcapper]

So after more testing I noticed the issue on two high DPI machines, when the app was restarted with a secondary monitor however it didn't happen (and would be fine on both). Some level of resizing could get windows to render, but if they got too wide it would go blank.

When using another test case, I noticed a 1920x1080 monitor seemed to have the same issue. The issue went away when "Let windows try to fix apps so they're not blurry" was turned off. I then pushed out a manifest having true/PM set figuring it would fix the issue and even with blurry on would not be a problem. Oddly this caused it to be blank always (with or without blurry setting on).

I figured I would see about testing this use case with similar settings (changing DPI aware to System aware rather than monitor) and turn of blurry and this issue went away.

I verified the DPI settings were properly applying (per task manager).

I am going to do more testing, there is a work around without disabling gpu flags to CEF but still odd.

[amaitland]

When the OSR implementation was updated to support the new Viz Compositor a lot of bugs were introduced, it's rather unusable at the moment unfortunately.

Some level of resizing could get windows to render, but if they got too wide it would go blank.

This should hopefully be fixed by https://bitbucket.org/xforce_dev/cef/commits/71856fa5cd6b04edf3b6ae25e40edbf6c220ad67 as mentioned in https://bitbucket.org/chromiumembedded/cef/pull-requests/256/pass-the-raw-size-of-pixel-data-instead-of/diff#comment-119600718

There's a reported problem with OSR rendering using High DPI see - https://bitbucket.org/chromiumembedded/cef/issues/2769/windows-offscreen-rendering-problem-with

Links for reference.

• https://bitbucket.org/chromiumembedded/cef/issues/2575/viz-implementation-for-osr
• https://bitbucket.org/chromiumembedded/cef/issues/2733/viz-osr-might-be-causing-some-graphic
• https://bitbucket.org/chromiumembedded/cef/issues/2483/osr-invalidate-does-not-generate-frame (This translates to WPF - Browser goes blank if used in combination with TabControl #2779, for which we implemented a hack, that hack is currently only in the cefsharp/75 branch).

[amaitland]

In version 75, disable-gpu-compositing was set by default https://github.com/cefsharp/CefSharp/blob/cefsharp/75/CefSharp.Wpf/CefSettings.cs#L25

[mitchcapper]

I can confirm requiring the hack similar to #2779 required for 77. While I have found the most compatibility with setting System DPI aware vs per monitor (with fix blurry apps off) there are other issues as well including the fact that if the DPI changes on the monitor the UI scales properly but touch / click points do not (only restarting the app seems to fix this).

[mitchcapper]

A few interesting things:
"disable-gpu-compositing" does fix it (although if used in a tabbed scenario the hack from #2779 is still required).

Without gpu compositing when it is affecting a machine the hack from #2779 can fix it for a single frame (bound the fix to a key combination for testing). For the tab issue running the #2779 fix fixes it until another resize (or visibility change) but for this issue while it can cause one frame to draw it doesn't fix it on an ongoing basis (so can't then scroll etc).
Further I have found if you "snap" the window to half the screen it works without any hacks (but maximizing, or any other sizes can result in the blank display).

Not sure what it all means, but continuing to investigate.

[mitchcapper]

So after some heavy v77 usage testing here is where I am at:
disable-gpu-compositing I enabled full time. After testing on a lot of machines it was the only consistent way to avoid some of these issues (depending on the chip the blank display unless the manual refresh is triggered for example). Without disable-gpu-compositing any change to the monitor DPI (ie removing a secondary display, etc) would cause the touch points to be off from the UI (so ui resized properly but click/touch points did not).

A lot of crashing still occurs, I have about 14 stack traces from crashes. Given #2953 however this may be moot. Will change over to v78 and see how much of this is resolved.

Even with "disable-gpu-compositing" the hack from #2779 is required for tab switching and such.

[amaitland]

Without disable-gpu-compositing any change to the monitor DPI (ie removing a secondary display, etc) would cause the touch points to be off from the UI (so ui resized properly but click/touch points did not).

Interesting, were you able to reproduce this with cefclient?

Will change over to v78 and see how much of this is resolved.

I've just updated master to 78.3.1+g8819d2e+chromium-78.0.3904.87 in commit 9668905 which should be the latest CEF version at time of writing.

Even with "disable-gpu-compositing" the hack from #2779 is required for tab switching and such.

That is unfortunate, I was hoping support for the Viz compositor would resolve that issue, I guess https://bitbucket.org/chromiumembedded/cef/issues/2483/osr-invalidate-does-not-generate-frame is a standalone issue.

[amaitland]

Three OSR issues were fixed

• https://bitbucket.org/chromiumembedded/cef/commits/508a66672f3482c744006ad473fe190741b8167d
• https://bitbucket.org/chromiumembedded/cef/commits/db0bbd3e915c08f85aa2e2ecb2f2880273bf9572
• https://bitbucket.org/chromiumembedded/cef/commits/e7df77819b73803c39aab9445d6a28bb4ecc4130

Another change needed would be related to the scaling where I am still not sure if I want to use visible_rect or coded_size, both seem to work fine on my machine.

I have a commit that basically has this change and another change that changes the if (view_size != content_rect.size()) { to use visible_rect.size()

Extract from comment. It references scaling, so possibly related to the DPI issue. Unfortunately the additional change hasn't been merged yet (nobody has submitted a PR far as I know).

[amaitland]

commit 617e43c upgrades master to CEF 78.3.9+gc7345f2+chromium-78.0.3904.108.

Disabling GPU Compositing is still required (at least on my 150% DPI machine).