994432 - HW acceleration gets disabled for one window only on Windows.

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Matt Woodrow (:mattwoodrow)]

+++ This bug was initially created as a clone of Bug #988862 +++

First heard about this while lurking in Mozillazine[1].

STR (steps 3-5 might take a few tries - I get it maybe once every 5 times)

1) Create a Firefox profile with many tabs - enough so that session restore has to take a little bit loading it. I had about 44 tabs when I reproduced this.
2) Go to Menu > Options, and in General, next to "When [brandname] starts", tell it to "Show my windows and tabs from last time"
3) Shut down the browser
4) Start up the browser, while repeatedly jamming Windows' "Show Desktop" button (that thing in the bottom right of the task bar).
5) Attempt to scroll a scrollable page.

AR:

HW acceleration gets disabled for this window, was showing up as bug 988862 before that was fixed.


Probably relevant log messages:

(In reply to Elbart from comment #47)
> Addendum to comment 39 point 1:
> 
> This is happening right before the message in the browser-console regarding
> D3D9 being initialized (as mentioned in comment 18):
> 
> (f50.ed8): C++ EH exception - code e06d7363 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=0019eae8 ebx=08c7e4b4 ecx=00000003 edx=00000000 esi=0019ef24 edi=00000000
> eip=75afc41f esp=0019eae8 ebp=0019eb38 iopl=0         nv up ei pl nz ac pe nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
> KERNELBASE!RaiseException+0x58:
> 75afc41f c9              leave
> 0:000> g
> (f50.ed8): C++ EH exception - code e06d7363 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=0019ec44 ebx=00000000 ecx=00000003 edx=00000000 esi=00000000 edi=08c7e1c0
> eip=75afc41f esp=0019ec44 ebp=0019ec94 iopl=0         nv up ei pl nz ac pe nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
> KERNELBASE!RaiseException+0x58:
> 75afc41f c9              leave
> 0:000> g
> (f50.ed8): C++ EH exception - code e06d7363 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=0019ef14 ebx=08d1f960 ecx=00000003 edx=00000000 esi=80070057 edi=00100260
> eip=75afc41f esp=0019ef14 ebp=0019ef64 iopl=0         nv up ei pl nz ac pe nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
> KERNELBASE!RaiseException+0x58:
> 75afc41f c9              leave
> 0:000> g
> Direct3D 9 DeviceManager Initialized Successfully.
> Driver: nvd3dum.dll
> Description: NVIDIA GeForce GT 640 
> 
> The stuff happening before these three exception is never the same. Once it
> was a pack of CSS-warnings, the other time a bunch of ModLoad-messages.

Comment 1

[Matt Woodrow (:mattwoodrow)]

Bas, this is probably most interesting to you. No if it's a recent regression, or we just recently had a way of spotting it.

Comment 2

[Bas Schouten (:bas.schouten)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #1)
> Bas, this is probably most interesting to you. No if it's a recent
> regression, or we just recently had a way of spotting it.

It might be interesting, but I don't think it's super-high priority, especially since LayerManagerD3D9 is going away and stuff might change a little around this code.

Comment 3

[Elbart]

Attachment: windbg_994432.txt

WinDbg-log (without the "JavaScript Warning"-spam) with the three exceptions being analyzed:

1. um:application_fault_e06d7363_d3d11.dll!cdevice::createtexture2d_worker
2. um:application_fault_e06d7363_d3d11.dll!ndxgi::cdevice::createsurfaceinternal
3. um:application_fault_e06d7363_dxgi.dll!cdxgiswapchain::createbuffers

Made with Nightly 2014-04-10.

Regarding recency or regression: I was able to trigger this switch(?) of Direct3D-modes with the mentioned session-loading-trick with builds from at least late August 2012. Around August 15th and 22nd the testing became harder and less successful, so maybe the change was in that range.

Comment 4

[Hani Yacoub, Desktop QA]

I couldn't manage to reproduce this issue. Since the bug was logged 8 years ago, most likely isn't reproducible anymore for the reporter also.
Closing this bug as resolved: Worksforme.