Is there an existing issue for this?
CefSharp Version
135.0.220
Operating System
Windows 11
Architecture
x64
.Net Version
.Net 4.8
Implementation
WPF
Reproduction Steps
Observed: When running ChromiumBrowser with threejs content at fixed 30FPS inside WPF app the dispatcher queue gets flooded with CefSharp.Wpf.Rendering.WritableBitmapRenderHandler+<>c__DisplayClass8_0.b__0 calls each taking an average of 100ms on Intel N97 during Windows Screen Lock / Monitor turn off. All settings default with multithreadedmessagepump=true and using gpu hardware acceleration.
The issue became noticeable when the wpf app was running in lock screen for several hours and after wake up all the queued up 'Frames' got redrawn rendering the device unusable for several minutes. A redraw storm after wake up situation or producer consumer problem. I did not find out the reason why wpf Dispatcher queue execution got throttled during the Monitor off scenario. The issue is not present on said hardware during normal operation when the screen remains turned on but I suspect it's some intel specific downclocking mechanism.
Another observation was that upon windows user change the Subprocess.exe kept using around 11% of the GPU (observed in windows taskmanager under GPU per process tab from other logged in user) while the WPF app's GPU usage was at 0% -> CefSharp produces more frames than the wpf app is consuming. The issue can be reproduced after around 3 minutes wait time.
In order to prove the Dispatcher queue buildup during Monitor off i had to write a custom Dispatcher Hooks Monitor that reads out DispatcherOperation.Name via reflection.
Expected behavior
No redraw storm after screen wakeup.
Actual behavior
The queued up WritableRenderHandler BeginInvoke / WritePixels calls get played back very fast like a redraw storm. The UI is unresponsive during the redraw storm until the frames are drawn and the 'flood 'is over.
Regression?
The issue was observed for 2+ years with previous CefSharp versions on a few notebook grade intel igpu chips of different generations.
Known Workarounds
Proposed solution: Add Frame coalescing via Interlocked.Exchange before BeginInvoke call to WritableBitmapRenderHandler and Remove the Lock/Unlock calls around WritabkeBitmap.WritePixels since those aren't necessary for WritePixels and only add overhead.
Does this problem also occur in the CEF Sample Application
Not Tested
Other information
Unsolved general problem: How to notify Subprocess.exe about lock screen to prevent it from consuming GPU resources while the User is locked ?
Is there an existing issue for this?
CefSharp Version
135.0.220
Operating System
Windows 11
Architecture
x64
.Net Version
.Net 4.8
Implementation
WPF
Reproduction Steps
Observed: When running ChromiumBrowser with threejs content at fixed 30FPS inside WPF app the dispatcher queue gets flooded with CefSharp.Wpf.Rendering.WritableBitmapRenderHandler+<>c__DisplayClass8_0.b__0 calls each taking an average of 100ms on Intel N97 during Windows Screen Lock / Monitor turn off. All settings default with multithreadedmessagepump=true and using gpu hardware acceleration.
The issue became noticeable when the wpf app was running in lock screen for several hours and after wake up all the queued up 'Frames' got redrawn rendering the device unusable for several minutes. A redraw storm after wake up situation or producer consumer problem. I did not find out the reason why wpf Dispatcher queue execution got throttled during the Monitor off scenario. The issue is not present on said hardware during normal operation when the screen remains turned on but I suspect it's some intel specific downclocking mechanism.
Another observation was that upon windows user change the Subprocess.exe kept using around 11% of the GPU (observed in windows taskmanager under GPU per process tab from other logged in user) while the WPF app's GPU usage was at 0% -> CefSharp produces more frames than the wpf app is consuming. The issue can be reproduced after around 3 minutes wait time.
In order to prove the Dispatcher queue buildup during Monitor off i had to write a custom Dispatcher Hooks Monitor that reads out DispatcherOperation.Name via reflection.
Expected behavior
No redraw storm after screen wakeup.
Actual behavior
The queued up WritableRenderHandler BeginInvoke / WritePixels calls get played back very fast like a redraw storm. The UI is unresponsive during the redraw storm until the frames are drawn and the 'flood 'is over.
Regression?
The issue was observed for 2+ years with previous CefSharp versions on a few notebook grade intel igpu chips of different generations.
Known Workarounds
Proposed solution: Add Frame coalescing via Interlocked.Exchange before BeginInvoke call to WritableBitmapRenderHandler and Remove the Lock/Unlock calls around WritabkeBitmap.WritePixels since those aren't necessary for WritePixels and only add overhead.
Does this problem also occur in the CEF Sample Application
Not Tested
Other information
Unsolved general problem: How to notify Subprocess.exe about lock screen to prevent it from consuming GPU resources while the User is locked ?