WPF/OffScreen resizing issue - Surface invariants violation

[karthik-sf]

Description:
while we doing resize the WPF application which uses cefsharp. it becomes hang and looks sluggish.

Steps to reproduce:
just resize front and back randomly 4 to 5 times continously.

Debug logs:
[1022/190426.141:ERROR:render_widget_host_impl.cc(2716)] Surface invariants violation: [OOPIF? 0] RenderWidgetSurfaceProperties(size(this: 566x669, other: 764x669))

[1022/190426.157:ERROR:render_widget_host_impl.cc(2716)] Surface invariants violation: [OOPIF? 0] RenderWidgetSurfaceProperties(size(this: 566x669, other: 764x669))

[1022/190426.174:ERROR:render_widget_host_impl.cc(2716)] Surface invariants violation: [OOPIF? 0] RenderWidgetSurfaceProperties(size(this: 566x669, other: 764x669))

any suggestions???thanks in advance:)

--

• What version of the product are you using?

  • What version are you using? Nuget? CI Nuget? build from a branch? If so which branch? Please include the exact version number you are using (no ambiguous statements like Latest from Nuget)
    e.g. 57.0.0 or 63.0.0-pre01
  • Please only create an issue if you can reproduce the problem with the latest version. (If you are using the latest stable release please check to see if there is a newer -pre release and test with that also).

• What architecture x86 or x64?

• On what operating system?

  • Win7, Win 8, Win10, etc?

• Are you using WinForms, WPF or OffScreen?

• What steps will reproduce the problem?

  • Please provide detailed information here, enough for someone else to reprodce your problem.
  • Please no binary (zip, etc) links, fork the MinimalExample and push your changes to GitHub. (Alternatively use a code sharing service list Gist or Pastebin).

• What is the expected output? What do you see instead?

• Please provide any additional information below.

  • A stack trace if available, any Exception information.

  • Does the cef log provide any relevant information? (By default there should be a debug.log file in your bin directory)

  • Any other background information that's relevant? Are you doing something out of the ordinary? 3rd party controls?

• Does this problem also occur in the CEF Sample Application from http://opensource.spotify.com/cefbuilds/index.html?

  • To compare with WPF run cefclient --multi-threaded-message-loop --off-screen-rendering-enabled
  • To compare with WinForms run cefclient --multi-threaded-message-loop
  • If you can reproduce the problem with cefclient then you'll need to report the bug on https://bitbucket.org/chromiumembedded/cef/overview there is no point opening an issue here. (Make sure you search before opening an issue)
  • Please include the version you tested with e.g. cef_binary_3.3029.1611.g44e39a8_windows64_client.tar.bz2

[Antonyo]

What version of the product are you using?
Build from master branch, commit 23b905d
Cannot recreate it in the latest release: CEF v67.0.0 or before

What architecture x86 or x64?
x86 and x64

On what operating system?

Windows 10

Are you using WinForms, WPF or OffScreen?
WPF, cannot recreate in WinForms

What steps will reproduce the problem?

1. Create a WPF Window with a browser inside it. The browser can be placed anywhere as long as it resizes along the container and therefore the window. For that purpose set the browser control alignment to stretch or default. The browser address can by anything.
2. Drag the window edge and resize it about 3 or 4 times, back and forth. It doesn't always occur with so that exact number of times, sometimes you have to resize it more or less times.

The address of the browser or the state of the browser doesn't affects the result.

What is the expected output? What do you see instead?
The browser stops rendering, the browser process is still alive and you can still execute javascript methods on it but, only the browser stops invalidating. The log contains the following error:

[1023/161156.142:ERROR:render_widget_host_impl.cc(2912)] Surface invariants violation: [OOPIF? 0] RenderWidgetSurfaceProperties(size(this: 984x684, other: 484x684))

the displayed width and height of the error message changes

Please provide any additional information below.
The checking that provokes the error seems to have been removed and merged: https://chromium-review.googlesource.com/c/chromium/src/+/1217706

By looking at the removed code you can clearly see that the render stops if the previous surface properties have changed from current ones and the error displayed in tuhe log indicates that those properties are the render size (displayed above).

It's also implicit that even that checking will be removed it's performed somewhere else in the code so it's either it was failing silently somewhere else in previous version or the state of the properties on that other check is correct.

Also

Does this problem also occur in the CEF Sample Application from http://opensource.spotify.com/cefbuilds/index.html?
No

Since I've tested it from the latest build it should have been been introduced in a CEF version following CEF 3.3396 which is the one included in the v67 release, after updating to CEF 3.3497.

I've created a fork of the latest master branch with a quick way to recreate in the Wpf.Example project; 3e96512
Simply run the Wpf.Example, SimplyMainWindow example will open. Click on the "Quick resize" button at the bottom window, one time should be enough.

[amaitland]

I've created a fork of the latest master branch with a quick way to recreate in the Wpf.Example project; 3e96512
Simply run the Wpf.Example, SimplyMainWindow example will open. Click on the "Quick resize" button at the bottom window, one time should be enough.

@Antonyo Thank you for completing the bug report 👍 I've run your code and am unable to reproduce the problem, no errors appear in the log. How many different machines have you tested on?

You can easily compare the two branches using cefsharp/67...cefsharp/69

Without a way to reproduce this there isn't much I can do.

[amaitland]

It's also implicit that even that checking will be removed it's performed somewhere else in the code so it's either it was failing silently somewhere else in previous version or the state of the properties on that other check is correct.

Possible, the changes that relate to size are

391fe82
a7c7384

They were also merged into the cefsharp/67 branch. You should have no problems reverting them and performing your tests.

[karthik-sf]

Hi team,

I have a questions on that,

you guys removed the error or fixed the hang issue??

if it is fixed, where i can get the latest dll's :)

[amaitland]

@karthikk2710 I've edited your original post to include the bug report template, please update with a completed bug report.

you guys removed the error or fixed the hang issue??

I have never seen the error before and as yet there is insufficient information to fix it.

For the time being you can use the WinForms version hosted in WPF.

[amaitland]

I'll also point out there are multiple OSR rendering issues currently open in the CEF issue tracker, it's entirely possible one of those is the root cause of this.

https://bitbucket.org/chromiumembedded/cef/issues/2506/osr-video-playback-cef3538
https://bitbucket.org/chromiumembedded/cef/issues/2511/osr-cef3497-stops-receiving-onpaint
https://bitbucket.org/chromiumembedded/cef/issues/2370/cefrenderhandler-onpaint-stops-receiving

[Antonyo]

Thanks for the info and sorry for not being able to help more. I was able to recreate the issue in 2 computers in any version after the update to Chromium 68.0.3440.75, right after the release of V67.

I don't think it's something related to CEFSharp code or anything related to how it handles the size, I am afraid is related to some changes in the workflow of the compositor thread architecture in Chromium.

Still I will try to find a way to fix it locally and keep an eye in CEF issue tracker.

[amaitland]

I was able to recreate the issue in 2 computers in any version after the update to Chromium 68.0.3440.75, right after the release of V67.

@Antonyo For reference what sort of GPU did those machines have? Both Win10? I take it you tested cefclient on both machines using cefclient --multi-threaded-message-loop --off-screen-rendering-enabled and both worked fine?

[amaitland]

https://bitbucket.org/chromiumembedded/cef/issues/2506/osr-video-playback-cef3538
https://bitbucket.org/chromiumembedded/cef/issues/2511/osr-cef3497-stops-receiving-onpaint
https://bitbucket.org/chromiumembedded/cef/issues/2370/cefrenderhandler-onpaint-stops-receiving

Two of these issues have been marked as closed, unable to reproduce in M70, anyone interested can try testing the master branch as it's been updated to the latest CEF build.

[Antonyo]

Thanks @amaitland I will take a look at it by Monday and report the results. Sorry for the late response, regarding your questions both machines were Win10 using integrated Intel chipset and I was never able to recreate in the cefclient.

[amaitland]

I'm running Windows 10 Pro 1709 with an Intel HD 4000 graphics adaptor, so similar hardware. Possibly the issue reproduces with a newer version of Win 10 (which was having issues with my hardware so I downgraded) or could be DPI related, I'm running with a DPI of 150%.

I was never able to recreate in the cefclient.

The only difference I can see is that CEF provides values in GetScreenInfo, for which I've added a very basic implemented in a10a5ef

[Antonyo]

I'm still able to recreate it even after updating to the latest commit. My configuration is similar Windows 10 home 1803 I tested in both an Intel HD 4600 and Nvidia GTX980 and in 100% and 150% DPI configuration and the result is the same.

However I can only recreate in debug configuration, in release configuration it works perfectly fine but also because the resizing is lightning fast for not having the debug symbols loaded.
To be honest I don't know what else to say, it works fine in release mode but in my opinion it doesn't mean that the error is not there only that it's very hard to recreate. I will try in a very slow computer to see if there's any difference.

[merceyz]

I'm able to reproduce the error in both debug and release versions of CefSharp.Wpf on a Windows 7 64 bit machine. x86/x64 made no difference

Using Process Hacker to simulate the worst case scenario the steps I used to reproduce was:

1. Set I/O priority to Very low
2. Set Priority to Below normal
3. Set Affinity to CPU 0
4. Then resized the form a bunch of times until I saw the error and it stopped drawing

With debug symbols loaded and a debugger attached to all processes I was also able to reproduce without following the steps above

Doing the same with cefclient --multi-threaded-message-loop --off-screen-rendering-enabled I was not able to reproduce the issue.

Here is the stack trace:

[1109/214156.190:FATAL:async_layer_tree_frame_sink.cc(141)] Check failed: last_submitted_size_in_pixels_.height() == frame.size_in_pixels().height() (159 vs. 327)

>	libcef.dll!logging::LogMessage::~LogMessage() Line 863	C++
 	libcef.dll!cc::mojo_embedder::AsyncLayerTreeFrameSink::SubmitCompositorFrame(viz::CompositorFrame frame) Line 142	C++
 	libcef.dll!cc::LayerTreeHostImpl::DrawLayers(cc::LayerTreeHostImpl::FrameData * frame) Line 2047	C++
 	libcef.dll!cc::ProxyImpl::DrawInternal(bool forced_draw) Line 670	C++
 	libcef.dll!cc::ProxyImpl::ScheduledActionDrawIfPossible() Line 535	C++
 	libcef.dll!cc::Scheduler::DrawIfPossible() Line 704	C++
 	libcef.dll!cc::Scheduler::ProcessScheduledActions() Line 804	C++
 	libcef.dll!cc::Scheduler::OnBeginImplFrameDeadline() Line 692	C++
 	libcef.dll!base::OnceCallback<void ()>::Run() Line 99	C++
 	libcef.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function, base::PendingTask * pending_task) Line 101	C++
 	libcef.dll!base::sequence_manager::internal::ThreadControllerImpl::DoWork(base::sequence_manager::internal::ThreadControllerImpl::WorkType work_type) Line 179	C++
 	libcef.dll!base::internal::Invoker<base::internal::BindState<void (viz::GpuServiceImpl::*)(int) __attribute__((thiscall)),base::WeakPtr<viz::GpuServiceImpl>,int>,void ()>::RunOnce(base::internal::BindStateBase * base) Line 662	C++
 	libcef.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function, base::PendingTask * pending_task) Line 101	C++
 	libcef.dll!base::MessageLoop::RunTask(base::PendingTask * pending_task) Line 436	C++
 	libcef.dll!base::MessageLoop::DeferOrRunPendingTask(base::PendingTask pending_task) Line 445	C++
 	libcef.dll!base::MessageLoop::DoWork() Line 517	C++
 	libcef.dll!base::MessagePumpDefault::Run(base::MessagePump::Delegate * delegate) Line 38	C++
 	libcef.dll!base::MessageLoop::Run(bool application_tasks_allowed) Line 388	C++
 	libcef.dll!base::RunLoop::Run() Line 105	C++
 	libcef.dll!base::Thread::Run(base::RunLoop * run_loop) Line 262	C++
 	libcef.dll!base::Thread::ThreadMain() Line 357	C++
 	libcef.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 103	C++
 	kernel32.dll!767d343d()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	Unknown
 	ntdll.dll!77379802()	Unknown
 	ntdll.dll!773797d5()	Unknown

No matter how many times I continue execution I get this:

Unhandled exception at 0x06D66C6E (libcef.dll) in CefSharp.BrowserSubprocess.exe: 0xC000001D: Illegal Instruction

>	libcef.dll!logging::LogMessage::~LogMessage() Line 863	C++
 	libcef.dll!cc::mojo_embedder::AsyncLayerTreeFrameSink::SubmitCompositorFrame(viz::CompositorFrame frame) Line 142	C++
 	libcef.dll!cc::LayerTreeHostImpl::DrawLayers(cc::LayerTreeHostImpl::FrameData * frame) Line 2047	C++
 	libcef.dll!cc::ProxyImpl::DrawInternal(bool forced_draw) Line 670	C++
 	libcef.dll!cc::ProxyImpl::ScheduledActionDrawIfPossible() Line 535	C++
 	libcef.dll!cc::Scheduler::DrawIfPossible() Line 704	C++
 	libcef.dll!cc::Scheduler::ProcessScheduledActions() Line 804	C++
 	libcef.dll!cc::Scheduler::OnBeginImplFrameDeadline() Line 692	C++
 	libcef.dll!base::OnceCallback<void ()>::Run() Line 99	C++
 	libcef.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function, base::PendingTask * pending_task) Line 101	C++
 	libcef.dll!base::sequence_manager::internal::ThreadControllerImpl::DoWork(base::sequence_manager::internal::ThreadControllerImpl::WorkType work_type) Line 179	C++
 	libcef.dll!base::internal::Invoker<base::internal::BindState<void (viz::GpuServiceImpl::*)(int) __attribute__((thiscall)),base::WeakPtr<viz::GpuServiceImpl>,int>,void ()>::RunOnce(base::internal::BindStateBase * base) Line 662	C++
 	libcef.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function, base::PendingTask * pending_task) Line 101	C++
 	libcef.dll!base::MessageLoop::RunTask(base::PendingTask * pending_task) Line 436	C++
 	libcef.dll!base::MessageLoop::DeferOrRunPendingTask(base::PendingTask pending_task) Line 445	C++
 	libcef.dll!base::MessageLoop::DoWork() Line 517	C++
 	libcef.dll!base::MessagePumpDefault::Run(base::MessagePump::Delegate * delegate) Line 38	C++
 	libcef.dll!base::MessageLoop::Run(bool application_tasks_allowed) Line 388	C++
 	libcef.dll!base::RunLoop::Run() Line 105	C++
 	libcef.dll!base::Thread::Run(base::RunLoop * run_loop) Line 262	C++
 	libcef.dll!base::Thread::ThreadMain() Line 357	C++
 	libcef.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 103	C++
 	kernel32.dll!767d343d()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	Unknown
 	ntdll.dll!77379802()	Unknown
 	ntdll.dll!773797d5()	Unknown

[amaitland]

I've had no luck reproducing this on my Windows 10 Surface Pro and unfortunately that's the only hardware I have at the moment (Only 4gb of memory so virtual machines aren't really an option).

Someone who can reproduce the problem will have to look into the issue.