
Intent to Implement: Display Locking - bpierre
https://docs.google.com/document/d/1mSQhTtaYFNy0qv5KifopEYm-ZKAZULnHyNcmKL8J4e0/mobilebasic
======
wallflower
This reminds me of the time many years ago when we worked on a VB app that had
to resort to the sledgehammer of Win32's LockWindowUpdate API call to do some
hefty calculations and not "freeze" the UI even though we were, in fact,
freezing the UI.

[https://docs.microsoft.com/en-
us/windows/desktop/api/winuser...](https://docs.microsoft.com/en-
us/windows/desktop/api/winuser/nf-winuser-lockwindowupdate)

------
jenscow
Better link: [https://github.com/chrishtr/display-
locking/blob/master/expl...](https://github.com/chrishtr/display-
locking/blob/master/explainer.md)

TD;DR: [https://github.com/chrishtr/display-
locking/blob/master/READ...](https://github.com/chrishtr/display-
locking/blob/master/README.md)

~~~
tmpmov
Interesting. My, perhaps wrong, visualization of the janking effect, without
the display update, concerns resizing, or showing, a column or pane in a web
app. During the resize, the content in both frames are not updated until the
resize is complete under certain (most?) conditions.

"If an undue delay is likely to be caused, the work already completed is
processed and the update phase yields to other update phases for unlocked
content."

My interpretation for a pane/column resize or hidden to visible operation:
display-locking reduces jank if I could operate on these elements with the
display lock tools. This jank reduction produces more fluid updates in
elements not affected by the lock.

Question: If sub elements have complicated draw/render cycles, how will the
interplay of locks at different layers affect the result? Composing objects
with libraries that use these locks makes me wonder about this issue (or if I
make sub-components myself).

------
CharlesW
Wow! When I first learned web development way back when, I was surprised that
something like HyperCard's _lock screen_ didn't exist/wasn't possible. Being
able to do this on an element level is a huge improvement over that. This is
great.

------
jessedhillon
Has there been substantial discussion about this feature? Neither of the two
links provided lead to deep discussions about this. It doesn't seem like this
is related to any agreed upon standards process.

As far as I can tell, this is being presented as a change to the programming
model which will be undertaken unilaterally. Are we back to the days where one
browser gets to decide how the web works, and everyone else can catch up if
they like?

~~~
aboodman
This is just about implementation, not shipping. It's still extremely early in
the process. See:

[https://www.chromium.org/blink/launching-
features](https://www.chromium.org/blink/launching-features)

------
bcoates
Is the point of this just to reduce visible jank, or to obsolete shadow-dom
implementations by replacing them with lock->modify->unlock?

------
duskwuff
There's a more detailed explanation of the proposed API at:

[https://github.com/chrishtr/display-
locking/blob/master/expl...](https://github.com/chrishtr/display-
locking/blob/master/explainer.md)

------
jedberg
TIL _jank_ is an actual term people use in formal documents.

~~~
vermilingua
Jank is an actual term, it’s the time-derivative of acceleration. Page jank
looks how motion jank feels; unexpected and uncomfortable.

~~~
dward
Jerk is the derivative of acceleration. I haven't heard jank used in that
context.

~~~
vermilingua
Brainfart, my bad.

------
mbrumlow
Will this allow content providers to lock content so that ad blockers can't
change the content ?

~~~
emsy
No, this is about increasing performance by taking elements out of the slow
DOM update cycle

~~~
phkahler
>> No, this is about increasing performance by taking elements out of the slow
DOM update cycle

The question was not about the intent of the feature, but a possible use case
that may not have been intended. A more specific reason for the "No" could be
more informative.

~~~
xg15
Interesting idea - though I think any kind of script API can be circumvented
by ad blockers pretty easily: They can always inject their own script before
anything from the page is executed and manipulate the API functions or replace
them with "do nothing" implementations.

------
AriaMinaei
This is one of multiple proposals to make DOM read/writes more performant.
More are listed here: [https://github.com/chrishtr/async-
dom](https://github.com/chrishtr/async-dom)

------
mcmatterson
For someone who doesn’t follow lower level browser dev that closely, this
seems like an optimization pretty specifically for a react style ‘nested
redraws’ use case. Is this at all correct?

~~~
ramses0
Basically "<ul id='foo'><li>...</li></ul>" && #foo.append( ...li... ) may
cause a redraw, recalc, reflow, of layout + styles for each LI you add to the
UL, as well as the rest of the dom containing the UL.

However if you can do: "BEGIN TRANSACTION; ...#foo.append(...)...; END
TRANSACTION;" it gives you a mechanism to "freeze" all or some of the display
(think of it as a subset double-buffer), and "blit" the changed dom to the UI
when you're done (with the possibility of: " && CONTINUE TRANSACTION".

Imagine a simple list of search results with alternating row colors (white /
grey backgrounds) specified by css (nth-child %2 == 0).

If you prepend elements, instead of appending elements it might cause all
elements to change color and re-render, on each insertion.

If you append elements instead then it's likely a more efficient on an
individual element basis than prepending, but if you had the ability to "lock"
the affected display area until you're done with your for-loop, then the
browser can avoid updating the area at all until the "COMMIT" call (multiple
actions, with a single commit resolution at the end).

Think of it as "batch these dom updates..." Git/SVN multi-file commits vs CVS
commits (single-file).

~~~
the8472
For many such cases, i.e. layout changes triggering the recalculation of
siblings or ancestors, contain[0] might be a more lightweight alternative.

[0] [https://developer.mozilla.org/en-
US/docs/Web/CSS/contain](https://developer.mozilla.org/en-
US/docs/Web/CSS/contain)

------
delinka
"...without jank."

Is this a technical term?

~~~
alangpierce
I think it's a reasonably common technical term in Android circles (possibly
elsewhere) that means "non-smooth animations" or "skipped frames".

[https://en.wiktionary.org/wiki/jank](https://en.wiktionary.org/wiki/jank)

------
Kenji
Why not just double-buffering the DOM? That'd be much simpler. Mutate your DOM
all you want, then swap it in when it's ready.

~~~
spankalee
This allows the browser to delay all style, layout, and paint work on attached
DOM, and then also spread that work across multiple frames during a commit,
reducing jank for the unlocked portions of the page.

If you synchronously swap a large portion of DOM, style, layout, and paint
will likely blow your frame budget.

~~~
ballenf
Either I don't understand double buffering very well (not unlikely) or I don't
know what you mean by "frame budget". Wouldn't swapping one buffer for the
other be faster than most or all of the computations going into calculating
that background buffer and easily doable in a single frame?

What am I missing?

~~~
dfox
Normal double-buffering involves doing something trivial at the moment of
buffer-swap, like changing pointer or at most doing large-ish memory copy.
Double buffering DOM would either not solve the problem (in the case of doing
the layout computations in background and then swapping already layed out DOM)
or would involve doing all the layout computations at once when the swap
happens (with the implication of this being mostly equivalent to loading new
page and thus slow and in many cases too slow to happen at 30, 60 or whatever
Hz)

