cefsharp/CefSharp

WPF - blank display and resize glitches/tearing

mitchcapper opened this issue · 20 comments

mitchcapper commented
  • 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 commented

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 commented

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 commented

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.

mitchcapper commented

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 commented

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 commented

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 commented

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 commented

Three OSR issues were fixed

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 commented

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).

amaitland commented

I'm about to push out a 79-pre release, both WPF and OffScreen have disable-gpu-compositing set by default. I have yet to see any issues when switching between tabs (#2779) so I haven't implemented the workaround as yet. If required I'll port the code into the cefsharp/79 branch.

There are two OSR issues that I'm aware of that cause rendering problems.

Both of which I've been unable to reproduce with GPU Compositing disabled.

master was updated to CEF 79.1.31+gfc9ef34+chromium-79.0.3945.117 / Chromium 79.0.3945.117 in commit 1550251

mayphi commented

@amaitland Looks like the workaround (#2779) is also needed for 79.
I tested it with the 79-pre (WPF) release with disable-gpu-compositing and after switching tabs a couple of times the browser goes blank.

amaitland commented

I tested it with the 79-pre (WPF) release

@mayphi What did you test with? What OS?

with disable-gpu-compositing

As in you left it disabled? Have you specified any other command line args?

Did you resize the browser to confirm that it redraws?

mayphi commented

What did you test with?

I tested it with the application we are currently developing.
With 75 everything seems fine.

What OS?

Win10 Pro (x64)

As in you left it disabled?

Yes.

Have you specified any other command line args?

--disable-gpu-compositing --disable-gpu-shader-disk-cache --proxy-auto-detect=1 --disable-gpu --enable-begin-frame-scheduling --disable-web-security=1 --user-data-dir=1 --disable-application-cache=2

Did you resize the browser to confirm that it redraws?

Yes, after a resize it redraws.

mayphi commented

@amaitland I can also reproduce this with the CefSharp.Wpf.Example (x64)

amaitland commented

I can also reproduce this with the CefSharp.Wpf.Example (x64)

@mayphi Thanks for confirming 👍

  • 👍1
amaitland commented

https://bitbucket.org/chromiumembedded/cef/pull-requests/284 should hopefully fix the resizing problems.

Shankp commented

with the cefrsharp 79.1.360,this glitch is available. is it known?
any fix for that??

amaitland commented

https://bitbucket.org/chromiumembedded/cef/issues/2733/viz-osr-might-be-causing-some-graphic has been resolved. master was updated in commit 3bac04d

I've removed the disable-gpu-compositing command line arg in commit 924e7bd

There is no hack for #2779 yet in master, that will be added when the next release branch is created.

There are some resize glitches that aren't present in the CEF Sample Application, I've created #3114 to track improving that.

Closing this now.