Windows 10 20H2)Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes
Problem description:
I use CefSharp with WPF on Intel 11th Core Iris Xe Integration graphic card, it can't redraw content. but when I closed WPF hardware acceleration, it can work normally.
Actual behavior:
open acceleration then CefSharp can't redraw content.
Expected behavior:
open acceleration, CefSharp can redraw content normally
Minimal repro:
the step for repeat problem can see from this Issues CefSharp
Looks like this is Intel's bug
Looks like this is Intel's bug
maybe, same build were tested on other platform, for example: Intel 10th Core CPU and 9th Core CPU, it work perfect.
Hi @LMing123. Thank you for the report. This is not something that can be fixed in WPF.
Hi @LMing123. Thank you for the report. This is not something that can be fixed in WPF.
I have a question that who should be fix this problem?
This is not something that can be fixed in WPF.
Assuming this bug-report is valid (I'm a bit skeptical about these sorts of reports since often the problem is in a driver and not the hardware/processor etc.)...
If one of those is the case, then only WPF can this remedy this problem. A (true) processor-specific bug - esp. one that affects a new CPU/GPU architecture as a class and .NET Core 3.1 (which suggests that it would likely affect .NET 5 as well) - ought to be treated as a bad problem and fixed as quickly as you can. Please consider investigating this further. Since this affects .NET Framework, clearly this also affects Windows 10 and Surface devices...
If this is a driver problem that's common to 11th gen Intel chipset's integrated GPU, I'm sure we have the ability to reach out to them through internal channels and work with them to fix their drivers so that hardware-accelerated rendering works as expected.
/cc @SamBent
Any news here?
I believe that there is _some_ kind of issue with Xe GPUs and WPF rendering, as we have a report of video not playing in one of our apps on a Xe GPU. I currently don't have access to a machine to test, but we use a WriteableBitmap, where we update the image by copying memory into its BackBuffer. Basically for each video frame we're drawing, we do:
b.Lock();
NativeMethods.CopyMemory(b.BackBuffer, buffer, bufferLength); // (win32 api CopyMemory)
b.AddDirtyRect(rect);
b.Unlock();
The outcome is that the first image renders successfully, but subsequent ones don't.
I may be able to provide more information and a minimal sample if I manage to gain access to such a machine and can find what exactly is causing the issue.
We also draw this from a separate Dispatcher running on its own thread (as in https://dwayneneed.github.io/wpf/2007/04/26/multithreaded-ui-hostvisual.html), but that could be unrelated.
The app is .NET 4.6.1.
Update: as expected, turning off HW acceleration for WPF through the Windows registry fixes the issue, but is not ideal.
CefSharp uses a WriteableBitmap when the DPI is greater than 100% and InteropBitmap for DPI of 100%. Not sure which implementation was used when @LMing123 experienced problems. Likely also using Writablebitmap. CefSharp uses the default dispatcher. I don't have access to hardware modern enough to reproduce this.
The https://github.com/cefsharp/CefSharp.MinimalExample project includes a simple WPF project that should reproduce the problem using CefSharp. If you use the CefSharp.MinimalExample.sln then perform a Nuget restore before opening in visual studio or perform a Nuget restore in visual studio then close and reopen the solution (it used to restore correctly in vs2013/2015, changes in visual studio make this a nessicary step, at least for now).
Does the .Net Core implementation of WPF differ enough to warrant testing to see if this reproduces?
It's possible this reproduces with InteropBitmap and WritableBitmap. Second report of this issue in the context of CefSharp https://github.com/cefsharp/CefSharp/issues/3300#issuecomment-739006981
CefSharp uses a WriteableBitmap when the DPI is greater than 100% and InteropBitmap for DPI of 100%. Not sure which implementation was used when @LMing123 experienced problems. Likely also using Writablebitmap. CefSharp uses the default dispatcher. I don't have access to hardware modern enough to reproduce this.
The https://github.com/cefsharp/CefSharp.MinimalExample project includes a simple WPF project that should reproduce the problem using CefSharp. If you use the CefSharp.MinimalExample.sln then perform a Nuget restore before opening in visual studio or perform a Nuget restore in visual studio then close and reopen the solution (it used to restore correctly in vs2013/2015, changes in visual studio make this a nessicary step, at least for now).
Does the .Net Core implementation of WPF differ enough to warrant testing to see if this reproduces?
The DPI I tested on 100% and 150%, it both have same problem. I also tested on dotnet core WPF, which same thing happened again. this test I used CefSharp.MinimalExample and default dispatcher.
By the way, when I continuously resize application window, the content rendering becomes normal.
I confirmed that a .net45 app (CefSharp.WPF) with WriteableBitmap has this issues.
The device is Dell Vostro 5301 with Iris Xe and NVIDIA MX350 graphic card. And the .net runtime is .net48 from Windows 10 2004.
Using NVIDIA graphic card in NVIDIA Control Panel or using software rendering in WPF can solve this.
And when resizing, it'll render the previous frame. So it'll seem to be normal when continously resizing.
Any updates for this issue?
Any updates for this issue?
there no any news , bugs still happily living.
Most helpful comment
I confirmed that a .net45 app (CefSharp.WPF) with WriteableBitmap has this issues.
The device is Dell Vostro 5301 with Iris Xe and NVIDIA MX350 graphic card. And the .net runtime is .net48 from Windows 10 2004.
Using NVIDIA graphic card in NVIDIA Control Panel or using software rendering in WPF can solve this.
And when resizing, it'll render the previous frame. So it'll seem to be normal when continously resizing.