WPF - Resize Glitches (Image glitches during resize)

[amaitland]

• What version of the product are you using?
  81.3.100

• What architecture x86 or x64?
  Both

• On what operating system?
  Win 10

• Are you using WinForms, WPF or OffScreen?
  WPF

• What steps will reproduce the problem?

  • Open CefSharp.Wpf.Example
  • Change window state to normal
  • Resize the browser fairly aggressively

• What is the expected output? What do you see instead?
  There are some glitches when resizing that aren't present when testing with cefclient

• Please provide any additional information below.
  DPI scale 150%

• Does this problem also occur in the CEF Sample Application
  No. The CEF Sample application isn't perfect when resizing, there's plenty of times the outer border is blank waiting for the image to resize correctly. The glitches aren't present to the same degree though.

[amaitland]

Use the disable-gpu-compositing command line arg should workaround the issue in the short term.

[amaitland]

Integrating CEF into the WPF message loop also appears to eliminate the glitches. Further debugging required.

Set multiThreadedMessageLoop = false in the example at https://github.com/cefsharp/CefSharp/blob/cefsharp/83/CefSharp.Wpf.Example/App.xaml.cs#L28

[rstedman]

Any update on this bug? I've found that CefSharp 79+ causes significant rendering artifacts when resizing a window. I get the same behavior with or without the --disable-gpu-compositing flag. example:

I can confirm that integrating cef into the wpf message loop gets rid of the rendering issues, but I am unable to do that in my usage of cefsharp as it causes some other issues.

I am able to update my application to 75.1.143 (from 67.0.0) without experiencing this rendering issue. Any higher version and this issue starts occurring.

I would really like to take the latest cefsharp version, as it has a fix for a css grid layout bug that occurs when viewing a page using cefsharp that doesn't occur in browsers (https://bugs.chromium.org/p/chromium/issues/detail?id=1051039). This resize bug is the only issue currently blocking me from taking latest.

[amaitland]

How does the CEF Sample application behave on your computer? See https://github.com/cefsharp/CefSharp/blob/master/CONTRIBUTING.md#cefsharp-vs-chromium-embedded-frameworkcef

[rstedman]

no issue with the cefclient

A coworker has also tested both the cefsharp wpf sample and the cefclient on their PC. They are seeing the same behavior as I am - render glitches in the cefsharp example and no issue with the cefclient.

[amaitland]

What command line args did you tested with?

The second animated gif where the scroll bar disappears and a black box occurs is more than likely a problem with the CEF OSR implementation, we're simplify rendering every frame we're given. Dumping each frame to disk in OnPaint and you should get a better understanding of what the output is.

I don't have any insight into what is causing the initial glitching, the rendering implementation hasn't changed in a long time, something changed in CEF/Chromium.

Resolving whatever issues you have integrating CEF into your apps existing message is possibly the simplest option. Though if you have time by all means have a go at debugging.

[amaitland]

You can view the cefclient source on GitHub.
https://github.com/chromiumembedded/cef/blob/8a055593d694b386f46530f81f53ed8b7c5ea284/tests/cefclient/browser/osr_renderer.cc#L280

The CefSharp rendering implentations are in https://github.com/cefsharp/CefSharp/tree/master/CefSharp.Wpf/Rendering
InteropBitmapRenderHandler is used when DPI is 100%
WritableBitmapRenderHandler is used when DPI is greater than 100%
DirectWritableBitmapRenderHandler is used when CEF is integrated into existing message loop.
There are some experiments You can try if you have time.

[rstedman]

I was using the command line args for the wpf/offscreen settings. I'll give debugging a shot.

[rstedman]

I've confirmed that this isn't a rendering issue in cef. I updated InteropBitmapRenderHandler to dump each frame to disk. Looking at the images that it output, they had no visual artifacts even though I was seeing the same tearing in the app while resizing.

I also found that forcing the ChromiumWebBrowser to use either the WriteableBitmapRenderHandler or the CompositionTargetRenderHandler under experiments would render without any visual artifacts when resizing.

Looking at the history of InteropBitmapRenderHandler, I found that this resize issue was introduced in this commit - an optimization to only create a new memory mapped file if the current file is smaller than the space needed. I've found that if I change

if (viewAccessor == null || viewAccessor.Capacity < numberOfBytes)
{
    ReleaseMemoryMappedView(ref mappedFile, ref viewAccessor);

    mappedFile = MemoryMappedFile.CreateNew(null, numberOfBytes, MemoryMappedFileAccess.ReadWrite);

    viewAccessor = mappedFile.CreateViewAccessor();
}

to

if (viewAccessor == null || viewAccessor.Capacity < numberOfBytes || currentSize.Width != width)
{
    ReleaseMemoryMappedView(ref mappedFile, ref viewAccessor);

    mappedFile = MemoryMappedFile.CreateNew(null, numberOfBytes, MemoryMappedFileAccess.ReadWrite);

    viewAccessor = mappedFile.CreateViewAccessor();
}

it resolves the issue.

before:

after:

I've spent a fair amount of time trying to figure out why reusing the larger memory mapped file for a smaller image is causing this tearing when the width of the image changes, but I'm at a loss.