It should be represented as a color layer which is very cheap. We should only composite it once. We will use a bit of memory bandwidth but nothing major, the main thread impact should be very small.
I agree, we should really have some data to support that drawing something like a display:none is causing a measurable slow down if this is the road we're going to go down. If we're just inefficient at it then I agree we should do better. I'd be surprised if we could not afford the main thread paint tick of a display:none page assuming we're not just hitting a performance problem. We'd have a nearly empty displaylist, no rasterization and it would use an async transaction to the compositor. On Thu, Jul 30, 2015 at 8:37 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > On Thu, Jul 30, 2015 at 4:27 PM, James Burke <jbu...@mozilla.com> wrote: > > > On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar <jmuizel...@mozilla.com> > > wrote: > > > Can't you just make everything display:none until you're ready to show > > it? > > > > Just using display: none seems like it will run into the same problem > > that prompted bug 863499, where the browser did some render/paints of > > a white page, which took time away from the async work completing. > > > > So maybe I should not frame it as just pausing layout? I was hoping it > > would also delay render and maybe paints that happen during startup, > > so more time is given up front to the async activities. > > > > Painting a document with display:none on the body should be more or less > free, I'd think. If it isn't, please file a bug. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
