Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Wed, Sep 7, 2011 at 9:04 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Sep 8, 2011 at 2:12 PM, John J Barton <johnjbarton@johnjbarton.com>
> wrote:
>>
>> Lack of information and explicit signals on when layout has been
>> triggered.
>
> Ok, let's fix that then. Adding a "window.getLayoutChangeCount()" method
> would be super-easy, for starters.

>From the tools point of view, a layout event would be better (it can
count). In the short run this makes the problem worse: now we are in
JS, do something that triggers layout, enter layout code, call JS
event handler for layout event, return to layout, return to JS. (The
event handler could be very expensive but it's up the tool/dev to deal
with that). I guess we call only if we have a handler set and the
handler would be per document or window so it's pretty cheap.

If the event has some info on how much the layout 'cost', then the dev
would see "OMG my function is firing 47million layouts at 10ms each!".

First however we need a way for devs to avoid triggering layout, in a
way that does not pin down the browser layout engine implementations.
Knowledge is an annoying thing when you can't do anything with it.

Is there/could there a way to take action on such info? Or maybe the
real question is more like: what prevents multiple JS ops from being
batched and triggering one or at least potentially fewer layouts.

(Apologies in advance if my point of view is ill informed).

jjb

Received on Thursday, 8 September 2011 05:05:45 UTC