On my Windows machine - a Lenovo W520 ThinkPad running Windows 7, the display is totally messed up if I run the latest nightly builds - the toolbars are blank and the wrong size, and the main display is black. As a result it is completely unusable for me. I'll attach a screenshot in a moment. Regression range: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-20-03-02-02-mozilla-central/ to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-21-03-02-00-mozilla-central/ Which equates to: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb9f34f73ebe&tochange=9d8d16695f6a

I'm guessing this is caused by enabling OMTC but it would be good to confirm that. Can you flip the pref (layers.offmainthreadcomposition.enabled) to see if that fixes things?

Here's my Graphics info from about:troubleshooting, running in the broken version (2014-05-21) in safe mode. Graphics -------- Adapter Description: Intel(R) HD Graphics Family Adapter Description (GPU #2): NVIDIA Quadro 1000M Adapter Drivers: igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32 Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: Unknown Adapter RAM (GPU #2): 2048 Device ID: 0x0126 Device ID (GPU #2): 0x0dfa DirectWrite Enabled: false (6.2.9200.16571) Driver Date: 3-6-2011 Driver Date (GPU #2): 5-25-2011 Driver Version: 8.15.10.2321 Driver Version (GPU #2): 8.17.12.6871 GPU #2 Active: false GPU Accelerated Windows: 0/1 Basic (OMTC) Vendor ID: 0x8086 Vendor ID (GPU #2): 0x10de WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: skia AzureContentBackend: cairo AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2) > I'm guessing this is caused by enabling OMTC but it would be good to confirm > that. Can you flip the pref (layers.offmainthreadcomposition.enabled) to see > if that fixes things? Yes, flipping the pref fixes it.

Does just flipping layers.direct2d.disabled to true ( reverting layers.offmainthreadcomposition.enabled) fix the issue for you?

(In reply to Bas Schouten (:bas.schouten) from comment #5) > Does just flipping layers.direct2d.disabled to true ( reverting > layers.offmainthreadcomposition.enabled) fix the issue for you? Yes, toggling either of those prefs works.

How about updating your driver?

Sorry for the delayed response. I've just updated to NVIDIA Quadro 1000M driver 9.18.13.3311 (Dated 29 April 2014) - from their website, not available by "update driver", and still get the same issue. There's an Intel(R) HD Graphics Family device at version 8.15.10.2321 (6th March 2011) but that says it is up to date, and I don't know where I'd find a new one of those.

(In reply to Mark Banner (:standard8) from comment #8) > Sorry for the delayed response. > > I've just updated to NVIDIA Quadro 1000M driver 9.18.13.3311 (Dated 29 April > 2014) - from their website, not available by "update driver", and still get > the same issue. > > There's an Intel(R) HD Graphics Family device at version 8.15.10.2321 (6th > March 2011) but that says it is up to date, and I don't know where I'd find > a new one of those. Bas, is that enough info, or have I missed a different driver somewhere?

(In reply to Mark Banner (:standard8) from comment #9) > (In reply to Mark Banner (:standard8) from comment #8) > > Sorry for the delayed response. > > > > I've just updated to NVIDIA Quadro 1000M driver 9.18.13.3311 (Dated 29 April > > 2014) - from their website, not available by "update driver", and still get > > the same issue. > > > > There's an Intel(R) HD Graphics Family device at version 8.15.10.2321 (6th > > March 2011) but that says it is up to date, and I don't know where I'd find > > a new one of those. > > Bas, is that enough info, or have I missed a different driver somewhere? Try the drivers here, it's generally lying with Intel when it says it's up to date. https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Laptop+graphics+drivers&ProductProduct=3rd+Generation+Intel%C2%AE+Core%E2%84%A2+Processors+with+Intel%C2%AE+HD+Graphics+4000&ProdId=3712&LineId=1101&FamilyId=39

We will likely turn off OMTC in Aurora by June 27th, but I'd like to track this as we can't really ship this kind of regression either way.

I've tried updating the intel driver from the website, but it says I can't install it due to having a custom driver already installed. So I took a look on getting an update from Lenovo, and the only graphics driver they had updated the NVIDIA driver but not the intel one :-( The relevant lines now look like: Driver Date: 3-6-2011 Driver Date (GPU #2): 10-28-2013 Driver Version: 8.15.10.2321 Driver Version (GPU #2): 9.18.13.1269 The good news is that I can now run the nightly build and it runs fine. Whereas it didn't before I updated the driver.

(In reply to Milan Sreckovic [:milan] from comment #11) > We will likely turn off OMTC in Aurora by June 27th, but I'd like to track > this as we can't really ship this kind of regression either way. With OMTC disabled on 32, is there anything left to fix on this branch? Tracking 32 and 33 until I know better.

I think we're fine on 32, though, theoretically, this problem existed before OMTC, just was very difficult to hit. We're leaning towards the blacklisting.

I've been having this problem for a Long Time now (since OMTC landed I guess). Blocks even profilemanager from running. https://pastebin.mozilla.org/5695967 Win7 W520 up to date. I know mreavy has the same problem

Had another report of this, need to ensure this gets fixed/blacklisted on Aurora. Matt, you have a W520 with Win7, can you work with Jesup (who's also seeing this) and/or Mark to figure out what's different about your machine and theirs?

Managed to get those drivers installed by downloading from dell and editing the inf file, can reproduce the issue now. We're getting a bunch of First-chance exceptions (_com_error) deep within CreateShaderResourceView (within DrawQuad) and it then returns E_OUTOFMEMORY. Not sure what to look at next, and it appears that the directx debug layer isn't working for me. This seems similar bug 1003293, vlad any suggestions on how you debugged that one?

A whole lot of trial and error, unfortunately. I was poking around the Optimus and other code and found a pattern that seemed to trigger the issues. But if it's an issue with an older driver, I'm not sure if there's anything we really should be digging into, short of blacklisting things.

If it's the default driver for W520 machines, then we might blacklist a large proportion of our d2d users that way. bjacob, do you have the tools you use for determining this available anywhere? If it's synchronization related, then it's possible that switching to d2d 1.1 might help. I can try looking for other drivers versions to narrow down when this got fixed.

15.21.7.64.2321 (8.15.10.2321) - Broken 15.21.13.64.2342 (8.15.10.2342) - Working Guess we need to know how many users we'll exclude if we blacklist all intel drivers older than 2342. Bas, do we have any contacts at Intel who we could ask about this? Seems like a fairly narrow range, so they might be able to figure out what fixed it and if any workarounds exist.

(In reply to Matt Woodrow (:mattwoodrow) from comment #20) > 15.21.7.64.2321 (8.15.10.2321) - Broken > 15.21.13.64.2342 (8.15.10.2342) - Working > > Guess we need to know how many users we'll exclude if we blacklist all intel > drivers older than 2342. > > Bas, do we have any contacts at Intel who we could ask about this? Seems > like a fairly narrow range, so they might be able to figure out what fixed > it and if any workarounds exist. Excellent work, I've sent a message to our Intel contacts. But I do share your concerns. For the DirectX debug layer, make sure you have the latest Windows SDK installed (8.1) and be sure to pass the DEBUG CREATE_DEVICE flags to the device creation calls. It should work fine then, although I haven't used it on Win7 for a while.

(In reply to Matt Woodrow (:mattwoodrow) from comment #19) > If it's the default driver for W520 machines, then we might blacklist a > large proportion of our d2d users that way. bjacob, do you have the tools > you use for determining this available anywhere? It's not really tools, it's just that the data is available online as CSV files at https://crash-analysis.mozilla.com/crash_analysis/ and those can be easily processed with bash one-liners. So if I understand correctly, the question is how much D2D usage would drop if we blacklisted drivers older than 2342. If I understand correctly, in a driver version like 8.15.10.2342, only the last part indicates the driver version, while the first 3 parts are characteristic of the Windows version. So for the sake of figuring how many drivers are older than 2342, we only need to look at the last part. Let's use crash data from yesterday (July 29). bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | wc -l 124211 bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | s 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l 42283 So overall, among Intel graphics users on windows, one third have driver < 2342 bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l 64582 bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l 10309 So if we restrict attention to people who are getting D2D, now the proportion of people with driver<2342 falls to 16%, or about 8% of the total. bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l 8333 bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l 859 So if we further restrict to people with a 2nd GPU, then the proportion of people with driver<2342 falls to 10%, and less than 1% of the total (because relatively few people with Intel graphics have a 2nd GPU). bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l 938 bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l 176 So if we still further restrict to people having this exact GPU 0x0126 (and have a 2nd GPU) then the proportion of people with driver <2342 is higher (close to 20%) but that's now only 0.1% of the total, because we've restricted the population so much. Finally, what if we restrict to device 0x0126, but dont restrict to having a 2nd GPU? bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l 3542 bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l 726 So we still have 20% of people with driver <2342, and the blacklisted population is still <1% of the total. Conclusions: * A whole lot of people have driver <2342, even if we restrict to people currently getting D2D. * But we can limit the number of people we blacklist by restricting to some specifics of the hardware that this bug is reported against --- either restrict to this device 0x0126, or restrict to having a 2nd GPU, or both --- either way gives you a blacklisted population smaller than 1% of total windows/intel users population.

(In reply to Benoit Jacob [:bjacob] from comment #22) > (In reply to Matt Woodrow (:mattwoodrow) from comment #19) > > If it's the default driver for W520 machines, then we might blacklist a > > large proportion of our d2d users that way. bjacob, do you have the tools > > you use for determining this available anywhere? > > It's not really tools, it's just that the data is available online as CSV > files at > https://crash-analysis.mozilla.com/crash_analysis/ > > and those can be easily processed with bash one-liners. > > So if I understand correctly, the question is how much D2D usage would drop > if we blacklisted drivers older than 2342. > > If I understand correctly, in a driver version like 8.15.10.2342, only the > last part indicates the driver version, while the first 3 parts are > characteristic of the Windows version. So for the sake of figuring how many > drivers are older than 2342, we only need to look at the last part. > > Let's use crash data from yesterday (July 29). > > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | wc -l > 124211 > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | s > 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk > '$1<2342' | wc -l > 42283 > > So overall, among Intel graphics users on windows, one third have driver < > 2342 > > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion | > wc -l > 64582 > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion | > sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | > awk '$1<2342' | wc -l > 10309 > > So if we restrict attention to people who are getting D2D, now the > proportion of people with driver<2342 falls to 16%, or about 8% of the total. > > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep > AdapterDriverVersion | wc -l > 8333 > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep > AdapterDriverVersion | sed 's/.*AdapterDriverVersion: > [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l > 859 > > So if we further restrict to people with a 2nd GPU, then the proportion of > people with driver<2342 falls to 10%, and less than 1% of the total (because > relatively few people with Intel graphics have a 2nd GPU). > > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU > #2' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l > 938 > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU > #2' | grep 'D2D[+]' | grep AdapterDriverVersion | sed > 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk > '$1<2342' | wc -l > 176 > > So if we still further restrict to people having this exact GPU 0x0126 (and > have a 2nd GPU) then the proportion of people with driver <2342 is higher > (close to 20%) but that's now only 0.1% of the total, because we've > restricted the population so much. > > Finally, what if we restrict to device 0x0126, but dont restrict to having a > 2nd GPU? > > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep > 'D2D[+]' | grep AdapterDriverVersion | wc -l > 3542 > bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz | > grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep > 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: > [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l > 726 > > So we still have 20% of people with driver <2342, and the blacklisted > population is still <1% of the total. > > > Conclusions: > * A whole lot of people have driver <2342, even if we restrict to people > currently getting D2D. > * But we can limit the number of people we blacklist by restricting to some > specifics of the hardware that this bug is reported against --- either > restrict to this device 0x0126, or restrict to having a 2nd GPU, or both --- > either way gives you a blacklisted population smaller than 1% of total > windows/intel users population. Great stuff Benoit, thanks a lot for this. Matt, as a first attempt I believe we should try to restrict to people with <2342 and a second GPU. That seems like a fair population to hit. Could you try and write the patch for that and test it on your machine? Unless you disagree with me and feel we should take another approach.

Do we have any reason to believe that this is actually dependent on having a second GPU? Since we don't have a suitable machine to test this on, and the bug appears to be entirely related to the intel driver version, then I'd think we'd be better of blacklisting this version in it's entirety. I tried creating D3D11 textures, and using DXGI to get the D310 texture for direct2d and that still fails. I also tried hooking up D2D 1.1 and that appears to work, except that it still has a fair few bugs (that I assume are because we haven't tried d2d 1.1 before).

I filed bug 1046550 with the patch I used for testing direct2d 1.1

(In reply to Matt Woodrow (:mattwoodrow) from comment #24) > Do we have any reason to believe that this is actually dependent on having a > second GPU? Since we don't have a suitable machine to test this on, and the > bug appears to be entirely related to the intel driver version, then I'd > think we'd be better of blacklisting this version in it's entirety. > > I tried creating D3D11 textures, and using DXGI to get the D310 texture for > direct2d and that still fails. > > I also tried hooking up D2D 1.1 and that appears to work, except that it > still has a fair few bugs (that I assume are because we haven't tried d2d > 1.1 before). Almost all of these more obscure bugs appear to be related to Optimus. But sure, just for good measure we could blocklist all. Did you try while disabling your nvidia graphics from the bios? It's interesting that 1.1 works, that surprises me. I do believe, considering the -huge- about of intel users on that driver version, and the fairly low amount of complaints, we can limit the blacklisting to this device.

It would be ironic to blacklist the default drivers on the laptops we distribute to employees... but, that said, it's better than losing even 0.1% of our users. It's too bad we can't figure out we're rendering everything as black at startup.... and just dynamically disable it. (Say search for a non-black pixel after the first window paints (or whatever, or on first Draw write a single white pixel and read it back) - should be a very cheap test if things work! - and disable 2d if we don't find any)

This failure was showing up as an HRESULT error in the compositor thread. I guess we could detect that and disable direct2d somehow. Not sure if we have infrastructure for that though.

Can we hack it by setting layers.direct2d.disabled to true after detecting this error? We will crash that time, but after that we would have auto-set the disabling of the d2d and wouldn't crash the next time? I don't know if there is enough time between seeing this error for the pref to get changed before we actually crash, if we're on the right thread to do it, if this error only shows up just before the crash, etc., just thinking out loud...

Setting a pref would mean permanent blacklisting, which would confuse users trying to address the issue by upgrading their drivers. It seems that the regular blacklisting conversation above is already advanced enough that we dont need to think about such more painful fixes.

(In reply to Matt Woodrow (:mattwoodrow) from comment #24) > Do we have any reason to believe that this is actually dependent on having a > second GPU? Since we don't have a suitable machine to test this on, and the > bug appears to be entirely related to the intel driver version, then I'd > think we'd be better of blacklisting this version in it's entirety. I'm sort of with Bas on this - it seems OK to blacklist either only this specific GPU or only dual-GPU systems until we get a definite bug report showing that's not enough - but don't care strongly. We just need to make a decision on this either way - blacklist only specific setup or all old drivers - but make one, let's not conflate into this immediate bugfixing conversation the more complex and long-term conversation of how to automatically detect D2D bugs and fall back to non-D2D, instead that would be OK material for a followup bug.

Damn, it appears direct2d 1.1 doesn't actually work. I had it setup sharing the same device between direct2d and the compositor which is racy. Using separate devices puts us back to requiring interop and fails in the same way. Unless we hear back from intel I think we should go ahead with blacklisting.

I also tried disabling the nvidia card/optimus using the bios, still broken.

https://hg.mozilla.org/integration/mozilla-inbound/rev/1e509bd9e284

Dropping tracking on 32 as OMTC has been disabled for 32.

Comment on attachment 8465939 [details] [diff] [review] Blacklist direct2d on this device Approval Request Comment [Feature/regressing bug #]: Bug 899785 [User impact if declined]: No rendering for some people [Describe test coverage new/current, TBPL]: Nightly [Risks and why]: Extremely low, blacklisting change. [String/UUID change made/needed]: None

fyi ... I recently installed Aurora 33a2 build 20140805004001 and it repeatedly crashed on start up. Because of a previous problem (black window on startup) I had preference <layers.offmainthreadcomposition.enabled> set to false. I edited <prefs.js> to change <layers.offmainthreadcomposition.enabled> to true and the problem was resolved. I don't have a pref named <layers.direct2d.disabled> ===================== Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0 Aurora 33a2 build 20140805004001 Laptop Lenovo T420 Windows 7 Configuration gfx.blacklist.suggested-driver-version 10.6 gfx.canvas.azure.backends direct2d,cg,skia,cairo gfx.direct3d.last_used_feature_level_idx 0 layers.offmainthreadcomposition.enabled true Graphics Adapter Description Intel(R) HD Graphics Family Adapter Description (GPU #2) NVIDIA NVS 4200M Adapter Drivers igdumdx32 igd10umd32 igd10umd32 Adapter Drivers (GPU #2) nvd3dum nvwgf2um,nvwgf2um Adapter RAM Unknown Adapter RAM (GPU #2) 1024 Device ID 0x0126 Device ID (GPU #2) 0x1057 Direct2D Enabled Blocked for your graphics driver version. Try updating your graphics driver to version 10.6 or newer. DirectWrite Enabled false (6.2.9200.16571) Driver Date 3-6-2011 Driver Date (GPU #2) 10-28-2013 Driver Version 8.15.10.2321 Driver Version (GPU #2) 9.18.13.1269 GPU #2 Active false GPU Accelerated Windows 2/2 Direct3D 11 (OMTC) Vendor ID 0x8086 Vendor ID (GPU #2) 0x10de WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0