Cefsharp: High DPI stops redrawing on Resize

Created on 1 Feb 2016  路  39Comments  路  Source: cefsharp/CefSharp

Issue Summary

First, the Webbrowser control correctly draws and redraws the webpage based on user interaction (e.g. clicking buttons, opening selects and size changes).

When the browser control gets hidden once, for example by changing to another tab and then gets displayed again, then it stops being redrawn after the window is subsequently resized.

No further user interaction triggers a redraw, except hiding and showing the control again (e.g. switching to another tab and back again)

It would be expected, that clicking buttons, opening selects and resizing the browser window should have visual effects.

Javascript actions are still being executed.

The info debug.log does not contain additional information.

Steps to Reproduce

  1. Start the CefSharp.Wpf.Example app
  2. Open a new tab
  3. Switch to the first tab
  4. Switch back to the 2nd
  5. Resize the Application
  6. The GUI has stopped updating.

This is a bug because the user can't interact with the browser anymore.

Animated gif captured with licecap: https://imgur.com/jXJtrrw

Technical details

  • CefSharp Version: latest nuget, latest github commit: 96e590055833e289829a99912facfb40d3256d09
  • Operating System: Win 8.1
  • x86/x64: x86
  • WinForms/WPF/OffScreen: WP
known-issue up-for-grabs upstream wpf

Most helpful comment

It would appear this has been resolved with the CEF commit above, I've updated master, so anyone can test, my limited testing with Windows 10 125% and it's working as expected now.

All 39 comments

@8 Thank you for the very detailed bug report :+1:

I'm guessing this is likely an incompatibility with your GPU. Are you using an Intel GPU by any chance?

Try disabling GPU acceleration.

https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Example/CefExample.cs#L70

I cannot reproduce your problem, and I'd expect that someone would have raised this issue before now if it was a wide spread problem.

Hi,

thank you for your quick reply!

I am on a nvidia GeForce GTX 860M and I have already tried the disable-gpu setting, but the problem persists.
//settings.CefCommandLineArgs.Add("disable-gpu", "1");

If you think it's gpu-related, I will try it out on a different system and get back to you!

Thank you,
-Martin

I've now run the Wpf Example App on another PC with Win10 and an AMD Radeon HD 5800 and the problem persists. If I resize the application after the tab second tab is visible again, the GUI stops responding.

Using the disable-gpu setting does not make any visible difference on the second machine either.

If anyone has some pointers I'd be grateful.

Take care,
Martin

the GUI stops responding.

Can you clarify what you mean by this? In your screen capture it's rather short, doesn't show you interacting with the browser other than resizing.

Try also disable-gpu-compositing with disable-gpu.
https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Example/CefExample.cs#L71

Hi, yes of course:
The browser does not update the UI anymore. Clicking links, buttons or hovering over elements do not have any visual effect. The clicks are registered and loading takes place but the UI is never updated to reflect those changes.

I've uncommented both lines in the example app before starting and debugger shows them being hit, but it has no effect.

Here is a slightly longer video showing the effects:
At first the UI works and after the hide/show/resize cycle it stops working.
http://imgur.com/ELUOzHP
In the second part of the video, I am clicking those links and buttons, but the browser does not respond visually.

In the second part of the video, I am clicking those links and buttons, but the browser does not respond visually.

Hmm, I can do the same without problem. So there has to be something else going on or I'm missing a step.

@8 Sample below, am I missing any steps?

wpf-example

Is the RendeProcess still alive?

Is the RendeProcess still alive?

In the WPF example it should load http://processcrashed/ when it crashes, obviously it's worth double checking. Also seeing if the Debug.log file has any clues. (Debug.log file is in the executing path/bin directory).

@amaitland Thank you for trying to reproduce it! You are doing exactly what I did and it's clearly still working for you.

I haven't seen any entry in the debug log when started in default mode, in verbose mode the info was - well - very verbose and I couldn't make anything suspicious out. The funky thing is, that I had the problem on my second machine as well.

As soon as I have the time I will dive in again - maybe it's some kind of software configuration that the machines share. Thank you all for your support!

@8 It is strange that it happens on multiple machines. I'll try on a Windows 7 machine tomorrow out of curiosity.

@8 What DPI were you running when experiencing the problem?

@amaitland: yes! You nailed it! DPI Settings at 125% (96*1.25=120) on both machines! Changed to 100% = 96 dpi and the error is gone! :D

We are currently facing the same issue where on the laptops that we are using, the default DPI is set to 125%. Changing the DPI to 100% also fixed this issue. In addition to this, we also found that we could also resolve it is by upgrading the graphic card drivers on the laptops (currently using NVIDIA Quadro). After upgrade to the latest driver, it works as well. However, I am wondering if there is other way to fix this issue instead of requesting our user to change the DPI or upgrading their graphic card drivers whenever they face this issue.

I'm using Nvidia Quadro as well...

After upgrade to the latest driver, it works as well.

Interesting, thanks for confirming :+1:

However, I am wondering if there is other way to fix this issue instead of requesting our user to change the DPI or upgrading their graphic card drivers whenever they face this issue.

By all means investigate further.

Prob worth trying WPF software rendering see if that makes a difference.
http://geekswithblogs.net/JeffFerguson/archive/2010/01/24/wpf-video-drivers-and-video-memory-leaks.aspx

By all means investigate further.

Follow up, I'll point out that with a DPI greater than 100 a different Bitmap is used. The standard InteropBitmap has a fixed DPI. Where as WritableBitmap allows you to specify a custom DPI.

https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Wpf/Rendering/BitmapFactory.cs#L15

Follow up on the steps provided by @8, I noticed the following:

  1. Start the CefSharp.Wpf.Example app
  2. Open a new tab
  3. Switch to the first tab
  4. Switch back to the 2nd
  5. Resize the Application
    The GUI has stopped updating.
  6. Switch to the first tab
  7. Switch back to the 2nd
    The GUI is working again.

@mykwgo If you force WPF to use Software Rendering does the problem reproduce?

Yes. I tried the following with much success.

RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;

Yes. I tried the following with much success.

Little bit confusing there. Did it work as expected or is there still a problem?

Sorry. I meant without much success. Sorry for the typo.

Is there a way to allow user to choose to have the browser use the default 100% DPI?

ie, For example in ChromiumWebBrowser->PresentationSourceChangedHandler

if (!useDefaultDpi)
{
matrix = source.CompositionTarget.TransformToDevice;
}

Is there a way to allow user to choose to have the browser use the default 100% DPI?

Not quite sure how that would work in practice.

@8 @mykwgo @jamespearce2006 Hopefully the three of you can work together on a solution. I'll leave you with it (I have other priorities at the moment).

What I ended up doing was rolling back to version 37.0.0 after examining the change log to see when dpi scaling was added, and for my intents and purposes this worked great after making some very minor changes to my pre-existing code. Obviously this is not an ideal solution, but it may help for you before this bug is addressed in a new update.

When we will get this fix?

When we will get this fix?

Use the WinForms version hosted in `WPF.

We use a hack to force the layout of the browser on resizing, it seems that it's not triggered after turned visible from hidden.
It's not a very elegant solution but since we use delayed resizing (resizing is not performed until the user stops dragging the mouse) it's not that critical for us.

The hack is here: 14896f67275cf4f135c2d72ae33b5209b4cc02cb

There seems to be an additional issue beyond that addressed by @Antonyo.
It looks like OnActualSizeChanged can be called before an HwndSource is created. That means that intermittently, OffScreenBrowser is created before the DPI is known (so 1.0 is assumed), which means the rendering gets screwed up.

I've modified the hack above to also handle the case where OnActualSizeChanged is called before PresentationSourceChangedHandler. In that case, the call to CreateOffScreenBrowser is deferred until the HwndSource is ready, and we know what the DPI is.

Here's my hack: 5a3c60f49ab7bf2befa2276cca7e60977a538037

It looks like OnActualSizeChanged can be called before an HwndSource is created.

Do you have steps to reproduce?

In that case, the call to CreateOffScreenBrowser is deferred until the HwndSource is ready, and we know what the DPI is.

Shouldn't be a need to modify the source, CreateOffscreenBrowser is virtual and can be override in user code.

Do you have steps to reproduce?

Not currently. It seems intermittent, and might be down to how we manage our UI workspace. I'll see if I can get it to happen with the test app.

...and can be override in user code

CreateOffscreenBrowser itself isn't the problem, it's when it gets called by ChromiumWebBrowser that can cause issues. If it is called before we have an HwndSource, we fallback to using 1.0 for the DPI, which will cause rendering problems

CreateOffscreenBrowser itself isn't the problem, it's when it gets called by ChromiumWebBrowser that can cause issues. If it is called before we have an HwndSource, we fallback to using 1.0 for the DPI, which will cause rendering problems

Rather than trying to modify the source, I'm suggesting subclassing ChromiumWebBrowser, override CreateOffscreenBrowser, have it do nothing, add some more event hooks and implement your changes in user code.

Got it - good point.

I had always assumed this was a problem with the CefSharp implementation, it however looks like it's an upstream issue an can be reproduced using cefclient (tested with cef_binary_3.3029.1613.g22354a9_windows32_client) from http://opensource.spotify.com/cefbuilds/index.html

Windows 10 Pro x64 build 14393.1066 with DPI set to 125%

Command line args used:

cefclient --multi-threaded-message-loop --off-screen-rendering-enabled

Simply minimize the window then restore, then resize the window.

Someone wishing to see this issue resolved should download cefclient, execute with the command line args listed above, if you can reproduce the problem then post on http://magpcss.org/ceforum/ asking for assistance.

Everyone experiencing this issue no further comment is required unless you're prepared to take responsibility and report the issue to the CEF project.

A bug with HiDPI scaling in CEF OSR has been fixed, unsure if it's related, should test when a build is available. See relevant commit https://bitbucket.org/chromiumembedded/cef/commits/8e694795d0e487a36ea4f277ae744772e87eaef7

It would appear this has been resolved with the CEF commit above, I've updated master, so anyone can test, my limited testing with Windows 10 125% and it's working as expected now.

Changes will be in the 63.0.0-pre01 release, closing this now. Comment if your still seeing a problem after upgrading to that version or higher.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

amaitland picture amaitland  路  20Comments

amaitland picture amaitland  路  29Comments

nico87 picture nico87  路  46Comments

amaitland picture amaitland  路  34Comments

brock8503 picture brock8503  路  23Comments