Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow speculative evaluation #439

Merged
merged 5 commits into from
Nov 9, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 14 additions & 4 deletions css-paint-api/Overview.bs
Original file line number Diff line number Diff line change
Expand Up @@ -451,7 +451,8 @@ Note: The user agent can optionally defer drawing images which are <a>paint-inva
</div>

The <a>draw a paint image</a> function is invoked by the user agent during the <a>object size
negotiation</a> algorithm which is responsible for rendering an <<image>>.
negotiation</a> algorithm which is responsible for rendering an <<image>>,
with |concreteObjectSize| set to the <a>concrete object size</a> of the <a>box</a>.

For the purposes of the <a>object size negotiation</a> algorithm, the paint image has no
<a>intrinsic dimensions</a>.
Expand All @@ -467,6 +468,15 @@ the <a>concrete object size</a> given by the user agent.
Note: See [[css-images-3#object-sizing-examples]] for examples on how the <a>concrete object
size</a> is calculated.

The <a>draw a paint image</a> function may be speculatively invoked by the user agent at any point,
with any |concreteObjectSize|. The resulting image is not displayed.

Note: User agents may use any heuristic to speculate a possible future value for |concretObjectSize|,
for example speculating that the size remains unchanged.

Note: Although the image is not displayed, it may still be cached, and subsequent invocations of
<<paint()>> may use the cached image.

<pre class='idl'>
[Exposed=PaintWorklet]
interface PaintSize {
Expand All @@ -478,12 +488,12 @@ interface PaintSize {
<div algorithm>
When the user agent wants to <dfn>draw a paint image</dfn> of a <<paint()>> function for a |box|
into its appropriate stacking level (as defined by the property the CSS property its associated
with), given its |concreteObjectSize| (<a>concrete object size</a>) it <em>must</em> run the
following steps:
with), given |concreteObjectSize| it <em>must</em> run the following steps:
1. Let |paintFunction| be the <<paint()>> function on the |box| which the user agent wants to
draw.

2. If the <a>paint valid flag</a> for the |paintFunction| is <a>paint-valid</a> the user agent
2. If the <a>paint valid flag</a> for the |paintFunction| is <a>paint-valid</a>,
and the previous invocation had the same |concreteObjectSize|, the user agent
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies that there can only ever be one speculative evaluation at a time. If we want to allow speculating multiple frames ahead, this should probably say something about checking for results of a speculative evaluation that match the input state.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the discussion of the paint valid flag is dubious, perhaps we should just delete it? It's very single-threaded. This is probably a separate issue though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a separate section which allows for the caching inside "invoke a paint callback", see step 10.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bfgeek yes, this is why I was thinking we could just remove all the stuff about the paint valid flag, since we're already allowing caching inside "invoke a paint callback". Shall I submit a separate PR for that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that sounds good, we still need to describe how the inputProperties invalidate that image on a box, but we can have that in prose vs. as an algorithm.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'll file an issue for this.

<em>may</em> use the drawn image from the previous invocation. If so it <em>may</em> abort
all these steps and use the previously drawn image.

Expand Down
20 changes: 20 additions & 0 deletions worklets/Overview.bs
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,26 @@ The following techniques are used in order to encourage authors to write code in

- User agents can create and destroy {{WorkletGlobalScope}}s at any time for these specifications.

Speculative Evaluation {#speculative-evaluation}
------------------------------------------------

Some specifications which use worklets ([[css-paint-api-1]]) may invoke methods on a class based on
the state of the user agent. To increase the concurrency between threads, a user agent may invoke a
method speculatively, based on potential future states.

In these specifications user agents might invoke methods on a class at any time, and with any
arguments, not just ones corresponding to the current state of the user agent. The results of such
speculative evaluations are not displayed immediately, but may be cached for use if the user agent
state matches the speculated state. This may increase the concurrency between the user agent and
worklet threads.

As a result of this, to prevent this compatibility risk between user agents, authors who register
classes on the global scope using these APIs, should make their code stateless. That is, the only
effect of invoking a method should be its result, not any side-effects such as updating mutable
state.

The same techniques which encourage code idempotence also encourage authors to write stateless code.

Infrastructure {#infrastructure}
================================

Expand Down