Created attachment 592603 [details] [diff] [review] Patch v1. While profiling imagelib, I noticed that GIF loading takes over 100ms at Firefox startup. The 11 GIFs take over 114ms compared to all other images take only 20ms to load. In particular I noticed that only 1 of the GIF images took almost the whole 114ms. On closer inspection, it didn't matter which GIF, just the first one to load causes the 114ms load time. Here's the profiling results in question: > NAME: mozilla::image::nsGIFDecoder2::WriteInternal > Count: 11 > Total: 0.114:04 > Min: 0.000:00 > Max: 0.114:04 > Average: 0.010:36 > App start time until first paint: 0.914:00 After digging deeper I found that almost the entire 114ms was taken from gfxWindowsPlatform::VerifyD2DDevice(), and in particular the calls to createD3DDevice. I found that we can take the 114ms above down to ~30ms with the following patch. What we do that causes the slowdown is first query for a D3D 10.0 device, followed by query a 10.1 if the 10.0 succeeded. Instead if we detect we can get the 10.1 we should try that first, then fall back to 10.0. So only the first load will ever be as slow as it used to be. For some reason querying both 10.0 and 10.1 takes significantly longer than half the time from just querying one. For a hot startup (not directly after a reboot) I have a startup time of average 912ms (until first paint) and a saving of average 62ms. So from testing I've seen between 3-10% speedups on startup for hot Firefox startup, I haven't tried with cold boots+startup but I suspect it won't be as significant.
I should mention my prefetch is also disabled via the other patch, so all numbers above are without prefetch. The speed gains from not having prefetch is not related to this patch though.
Comment on attachment 592603 [details] [diff] [review] Patch v1. Bas wrote this code, and he, I presume, had a reason for trying 10.0 first.
It still tries 10.0 first, but after it knows that 10.1 is avail it will try 10.1 first. If 10.1 becomes unavail it reverts back to 10.0 first.
Comment on attachment 592603 [details] [diff] [review] Patch v1. Review of attachment 592603 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/thebes/gfxWindowsPlatform.cpp @@ +359,5 @@ > + // a createD3DDevice on D3D10_FEATURE_LEVEL_10_0 and > + // D3D10_FEATURE_LEVEL_10_1. Therefore we set a pref if we ever get > + // 10.1 to work and we use that first if the pref is set. > + // Going direct to a 10.1 check only takes 20-30ms. > + HRESULT hr = E_FAIL; A little documentation around the logic surrounding this initialization and how it affects the rest of the flow would be nice :).
Created attachment 595627 [details] [diff] [review] Patch v2. Thanks for the review! Updated patch with the initialization explained in the comment. Carrying forward r+. Pushed to try, and I will push to inbound once that passes tomorrow.