nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Blank map when WPF is in software rendering mode

chrishibler1

Hello, in 100.3, using WPF I'm seeing a blank map with nothing at all rendered when the hosting WPF application has fallen back to software rendering mode. Unfortunately, our desktop application is required to work in this case because there are some circumstances in which WPF uses software rendering that are outside of our control.

This is reproducible by setting RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly.

I'm guessing this could be because the D3DImage.SetBackBuffer method is being called without the optional parameter to fallback to software rendering.

Is there a solution or workaround for this?

Find more posts tagged with

Accepted answers

SomeGISGuy

Thank you for confirming. We've added a fix to Update 5, so that If your system reports 0 for the Rendering Tier, it'll automatically switch to software rendering mode, so this should "just work" soon. At the devsummit last week we were announcing that we hope to release U5 at end of March / early April if all things go well.

All comments

MichaelBranscomb

Hi,

This should be resolved in the v100.5 release of ArcGIS Runtime SDK for .NET.

Please can you update, retest, and confirm?

Cheers

Mike

SomeGISGuy

chrishibler1

Our application uses VNC for some unrelated features and in some cases the setup to make that work prevents hardware rendering. I think it probably doesn't work over RDP in all cases either (I haven't verified this, but we've seen problems with hardware rendering from other components).

The System.Windows.Media.RenderCapability.Tier on a non-working system is 0. We log this in our app and use that value to indicate software rendering for other things. We've been able to rely on that value for our situation.

The registry key HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics\DisableHWAcceleration doesn't exist on any either system I checked.

Thanks again!

SomeGISGuy

Two more things...

Could you try and report the value returned by "System.Windows.Media.RenderCapability.Tier" on a system that doesn't work vs a system that does?

Also is the HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics\DisableHWAcceleration value set in the registry ? (and if so to what)

That would be immensely helpful.

SomeGISGuy

Thank you for confirming it's returning default. My idea for a fix was to check this value and if returns software, we'd force software rendering. Unfortunately that doesn't seem to be the case, so we need to find some other sort of indicator to provide a fix- I'd need to set up an in-house reproducer so we can find a better fix.

It would be awesome if you could share as many details about the systems you are experiencing this issue on, so we can try and set up a similar environment.

Also if you could press Win+R and enter "dxdiag" and OK to run the DX Diagnostic tool, then click "Save All Information" and share the generated report, that would be very useful as well (if you can email it to mnielsen (at) esri.com).

Thank you for helping us tracking this down!

DritanZhuja

Hello Morten,

This workaround is very helpful for us as the issue was showing up on some PC's but not others when we decided to move from Runtime 100.1. to 100.3.

While testing on the PC's that had the issue with the blank map to see what the RenderOptions.ProcessRenderMode was being set to, the value was "Default".

Using the RenderMode.SoftwareOnly forced the PC's that didn't have the issue to show the same symptoms, but in any case adding the line of code you recommended is a very welcome workaround.

We also tested the PC's that had the issue with Runtime 100.2.1 and 100.4. The issue was not present running on 100.2.1 but it persisted with 100.4 as it did with 100.3.

All this being said, do you think this is something that will be fixed in the future releases of ArcGIS Runtime 100.x?

SomeGISGuy

I'd like to understand your scenario a little better where software rendering happens, so that we can better auto-detect it in a future release. Could you share a little more about the environment you run in that causes software rendering (we should have auto-detected and fallen back to software, this but apparently with your setup that doesn't work).

When you don't set RenderOptions.ProcessRenderMode but check it on this specific system does it return software mode, or still return default? (ie I'm trying to understand if it's sufficient for us to just check this value)

chrishibler1

Thank you for your reply, we'll try the workaround you suggested.

Just a clarification, we're not explicitly setting the process render mode, WPF is choosing software rendering in our application. Checking the value of RenderOptions.ProcessRenderMode wouldn't cover our real-world case, setting it is just a convenient way to reproduce the problem.

Thanks again for your support!

SomeGISGuy

We'll look into improving this, so if this property is set, we'll auto-switch to software rendering. Until then, you can use this temporary workaround (but be aware that since this is using reflection to flip a switch, it might not continue to work in future versions):

typeof(Esri.ArcGISRuntime.ArcGISRuntimeEnvironment).GetMethod("ForceDxSoftwareRendering", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static).Invoke(null, null);

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.