I just upgraded my ATI videos drivers from 10.2 to 10.3a and I left Minefield open and when the upgrade was finished, I went back to the browser and Minefield was blank except for the title bar. All of the controls, menus, etc were gone. Minimizing and maximizing didn't fix it. I had to restart the browser. Even the save tabs and quit box was blank except for the title bar. I'm guessing Minefield doesn't know what to do if it loses the GPU during a driver upgrade?

Yes, we need to support device resets. We know about this problem.

So this poses a very interesting question, there's too possible ways of dealing with this: 1. Setting the surface into a special error state when this occurs. Code above will deal with this by recreating the surface and invalidating the entire surface content or otherwise falling back to GDI rendering. 2. At all times keep a copy of our surface content in software RAM for each D2D surface (as it was done in GDI). This readback would not incur performance overhead since the software surface will be written back to asynchronously and will only synchronize if there are attempts to map the surface. This also points out an obvious flaw in this approach, if the device is reset the readback can no longer be synchronized, therefor drawing commands which were still in the pipeline might be lost. Causing rendering artifacts. My preference goes to approach 1, first of all since the weakness already illustrated in approach 2. Second of all because if a D3D10(Level9) device was removed completely, and no D3D10 capable device is present, we can't deal with this inside the D2D surface, since the machine will no longer be D2D capable. The first approach is also probably more in line with a cairo_device_t approach.

Is it possible that device reset now causes a crash? I just updated my drivers and when screen returned, bp-0da6a21b-8be3-4629-8454-6af732100918. Note it's a weird crash report, with no stack, no modules, no extensions listed. Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre Driver update from 10.8 to 10.9 on a hd5850. Direct2D Enabled true DirectWrite Enabled true Haven't tried to reproduce.

(In reply to comment #3) > Is it possible that device reset now causes a crash? I just updated my drivers > and when screen returned, bp-0da6a21b-8be3-4629-8454-6af732100918. > Note it's a weird crash report, with no stack, no modules, no extensions > listed. > > Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100917 > Firefox/4.0b7pre > Driver update from 10.8 to 10.9 on a hd5850. > Direct2D Enabled true > DirectWrite Enabled true > Haven't tried to reproduce. It shouldn't! Atleast not when you're also using D3D9 layers (which you should, in the case of your machine). It should even recover in the nightly from the 17th and later.

Hmm, the crash kind of looks like what you'd have if you were not getting D3D9 layers (except it doesn't have the symbols), but the address and the exception match. Did you have layers.accelerate-none set to true by any chance?

(In reply to comment #5) > Did you have layers.accelerate-none set to true by any chance? Nope. layers.accelerate-all;true layers.accelerate-none;false. I can't tell you what was the status of "GPU Accelerated Windows" at the time of crash, but it's now simply all of them. My Steam client decided to perform another driver update (what a silly software) and minefield crashed again. This time it was bp-9c86fdcb-ee8a-4ba3-b063-e53362100918 which is just bug 592595.

(In reply to comment #6) > (In reply to comment #5) > > Did you have layers.accelerate-none set to true by any chance? > > Nope. layers.accelerate-all;true layers.accelerate-none;false. I can't tell you > what was the status of "GPU Accelerated Windows" at the time of crash, but it's > now simply all of them. > > My Steam client decided to perform another driver update (what a silly > software) and minefield crashed again. This time it was > bp-9c86fdcb-ee8a-4ba3-b063-e53362100918 which is just bug 592595. This is very confusing. That code should not be reached when you're using D3D9 layers. I'll need to think about this.

I think I hit this today with my updated Nvidia drivers. Would a reset need to fire an paint for all open browser windows?

Bas, I haven't encountered this bug in a while, I think Firefox handles video driver updates more gracefully than at the time this bug was filed. Might be safe to close.