Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Wed, Sep 7, 2011 at 10:34 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Sep 8, 2011 at 5:04 PM, John J Barton <johnjbarton@johnjbarton.com>
> wrote:
>>
>> 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.
>
> It would be difficult to expose a synchronous "onlayout" event to Web
> content safely, and it would be pointless to make it asynchronous.
>
> Some sort of debugger-level event would make sense, but that doesn't need to
> be standardized.

I really don't understand this logic. Why does the HTML and CSS
support in dev tools work well? Because the features are well
supported. Why is the JS support so buggy? Because the features aren't
standard and thus are not well supported.

A reasonable objection is lack of existing practice to inform
discussions.  But it's extremely difficult to get platform teams to
invest in tool-only support. All we get are gifts from random efforts.

>
>> 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!".
>
> That sounds like something good for a debugger-level timeline API. Or
> *maybe* web-perf.
>
>> 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.
>
> You need to know what makes layouts dirty, and what requires dirty layouts
> to be brought up to date.
>
> Almost all DOM changes can make layouts dirty. Almost all CSSOM (Views) APIs
> require dirty layouts to be recalculated. That's a good start...

No, that's *almost* a good start. Put yourself in a Web dev's sandals:
If you reorganize your code you may cause fewer layout changes.  Or
not. For sure you will break your app.
It's fine if you don't have anything else to do...

A list of JS calls that for-sure cause layout and a list that
for-sure-do-not would be a good start. Is that possible?

jjb

Received on Thursday, 8 September 2011 15:04:11 UTC