search

wilsonpage / fastdom

Eliminates layout thrashing by batching DOM measurement and mutation tasks
6.83k stars 240 forks source link

Order of read/write queues #49

Closed Pauan closed 9 years ago

Pauan commented 9 years ago

I noticed that the read queue is run before the write queue. I'm curious: what are the reasons for running read before write?

wilsonpage commented 9 years ago

Writing to the DOM 'invalidates' the current layout, meaning any subsequent reads in the same frame will force a layout. Reading from a clean/valid DOM is free, and doesn't force a layout.

Therefore reading and then writing is the most efficient way to flush the queue.

Hope that answers your question. On 7 Nov 2014 15:37, "Pauan" notifications@github.com wrote:

I noticed that the read queue is run before the write queue. I'm curious: what are the reasons for running read before write?

— Reply to this email directly or view it on GitHub https://github.com/wilsonpage/fastdom/issues/49.

Pauan commented 9 years ago

So what you're saying is, letting the browser run the relayout on its own time, after the current requestAnimationFrame but before the next one, is faster than forcing a relayout in the current requestAnimationFrame? If so, then that does answer my question, thanks.

wilsonpage commented 9 years ago

Yeah, that sounds correct to me. May your apps be fast :)

On Tuesday, November 11, 2014, Pauan notifications@github.com wrote:

Closed #49 https://github.com/wilsonpage/fastdom/issues/49.

— Reply to this email directly or view it on GitHub https://github.com/wilsonpage/fastdom/issues/49#event-191070441.