692121 - Using a timer to start d3d interferes with tests

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

In the windows nsToolkit::Init we create a timer that enables d3d9. This means that some tests can run with d3d9 or not depending on the bot speed.

We should have some way of forcing it on or waiting for it before running tests.

Comment 1

[(dormant account)]

Bas, this is also really bad for startup speed. This penalizes users of slow machines too much(ie if your startup is >=5s, then you are gonna pay an extra d3d9 tax). Would be nicer if this setup an nsIobserver and waited for either "window-displayed"(I don't know the exact name or "session-restored" notification before setting up the timer.

Once we have an IO queue, we'd get rid of the timer altogether.

Comment 2

[Bas Schouten (:bas.schouten)]

We could just up the timer to 30s to solve that problem. There's no need to switch accelerated layers on 'as soon as possible'.

Comment 3

[Emanuel Hoogeveen [:ehoogeveen]]

I think there are some use cases where forcing hardware acceleration to initialize would be desirable. For instance, what if a power user alternates between two builds of Firefox to run some HWA-sensitive benchmarks? Setting the timer to 30 seconds makes it much more likely that the benchmark will start out unaccelerated, invalidating the results.

Comment 4

[Bas Schouten (:bas.schouten)]

Perhaps, but that's a testing error in a way (i.e. not understanding your testing conditions, 'about:support' will actually show you're unaccelerated). Although admittedly, that would suck.

Arguably though, if firefox is taking 5s to startup, the 50-100ms from D3D9 isn't going to matter too much. But okay, that issue is getting away from this bug a little, I guess the bottom line is we want a pref we can set to make it initialize on startup, always?

Comment 5

[(no longer active)]

So I think the original title of the bug is WORKSFORME, since we'll get accelerated layers as soon as a canvas is used, which I think would cause the reftests to always run in accelerated mode.

Feel free to reopen and morph into other issues, or file separate bugs.