- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 27 Aug 2017 14:32:17 -0400
- To: public-houdini@w3.org
- Cc: www-style@w3.org
=================================================
These are the official Houdini Task Force
minutes. Unless you're correcting the
minutes, please respond by starting
a new thread with an appropriate subject line.
=================================================
CSS Properties & Values
-----------------------
- RESOLVED: Inherits argument is required
- RESOLVED: Publish Properties and Values as WD and announce
intent to transition to CR soonish.
Custom Paint
------------
- Issue #406 (Speculative evaluation) will be added to custom pain
instead of workers.
- RESOLVED: No change on Issue #348 (Consider making Path2D the
only way to render paths with PaintRenderingContext2D)
- RESOLVED: Object called contextAttributes (Issue 435: Remove
alpha flag, in favor of a contextSettings flag?)
- RESOLVED: Add devicePixelRatio to canvasContext, other MQs can
be accessed via custom properties (Issue 436: Consider
adding property for expected rendered bitmap size)
- RESOLVED: Republish Paint API spec, announce intent to
transition to CR and request last round of review
feedback
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Paris-F2F-August-1st-2017
Scribe: fantasai
CSS Properties & Values
=======================
Inherits should be true by default
----------------------------------
Github: https://github.com/w3c/css-houdini-drafts/issues/434
iank: Is leaverou coming?
fantasai: No she's down under.
iank: She filed an issue last week might be useful to talk about.
TabAtkins: Question is should registered custom properties be
inherited by default.
TabAtkins: Regular custom properties are inherited by default
TabAtkins: Lea and Ana found it confusing that registered ones
don't.
TabAtkins: The standard for doing option bags is that an
unspecified one defaults to something falsy
TabAtkins: i.e. undef is false
TabAtkins: If you don't define a flag, we treat it as false
TabAtkins: We could swap the boolean.
....
<dbaron> https://w3ctag.github.io/design-principles/#prefer-dict-to-bool
dbaron: ...
[scintillating naming discussions]
franremy: Maybe it should be required.
iank: Can we make the parameter in the dictionary required?
TabAtkins: Seems like best option, to make it a required key.
franremy: Non-inherited is good for performance.
iank: Good idea to make sure author has to decide.
SimonSapin: Gecko uses reset for properties that don't inherit.
dbaron: That's not web-exposed though.
TabAtkins: I prefer making argument required, so ppl don't default
into non-performant option.
RESOLVED: Inherits argument is required
Publication/Shipping
--------------------
iank: We have just a few more things to fix before shipping.
fantasai: So, you're like "we got a few bugs and then we're going
to ship it".
fantasai: What's the state of the spec,
fantasai: Has it been published recently?
...
fantasai: If it hasn't been published recently but is reasonably
stable, then let's publish ASAP, send out Last call for
Comments announcements, and prep for CR.
fantasai: Any reason not to do that?
RESOLVED: Publish Properties and Values as WD and announce
intent to transition to CR soonish.
fantasai: If implementations are getting ready to ship something,
and the spec is not in CR, then we should be putting the
spec in CR.
fantasai: Because the process for doing so triggers review from
people who aren't paying attention because last they
heard was it was an exploratory early-stage working
draft.
fantasai: It's better to solicit people's comments before
shipping, so we should make an effort to publish and
announce the intent to transition before we ship things.
fantasai: (Sometimes it's not possible to make the transition,
e.g. for Transitions /Transforms / Animations, there's
a chunk of work blocking CR even though implementations
have shipped already, but in the general case we should
try to get the specs to CR ahead of shipping)
fantasai: This also signals to other implementations who don't
have Google's vast resources to rewrite things multiple
times that the spec has stabilized and now is a good
time to implement :)
<SimonSapin> fantasai +1
<Rossen> Implementation status: Chrome is shipping the an
experimental work in Canary. Mozilla has a developer
working on it as well. Microsoft and Apple are under
consideration
TabAtkins: Constructors don't do CSS parsing, everything is fine
franremy: Some browsers expose constructors, expose some object
that's not a function...
TabAtkins: Let's not do that
Rossen: So for custom paint, anything to discuss?
Custom Paint
============
Speculative evaluation
----------------------
Github: https://github.com/w3c/css-houdini-drafts/issues/406
till: Ideally we'd have future-proofing similar to tearing down of
worklets now and again for this as well, but to really do
that would require existing impls to do speculative
execution for no good reason at all.
till: That's a hard sell, so that's not what we're asking for.
till: What we are asking for is to explicitly allow speculative
execution in the spec.
iank: Basically what we're asking for is a section like " ... user
agents my speculatively invoke this function, giving what it
thinks it an object size and size could be at a future point
in time"
till: We'll work on a PR.
iank: I think this belongs in the paint spec, not the worklets
spec though.
till: Ideally we should have ability to do this in as many
worklets as possible, but doesn't make sense in other places.
iank: Maybe say in worklets spec that downstream specs may choose
to do this.
dino: What would be an extra parameter?
dino: What's the API for this?
dino: There's a paint function that gets size and style map.
iank: No additional API.
dino: Just the style map would have speculative?
iank: Yes
till: Should already be somewhat future-proofed because of req in
spec intended to prevent you from relying on state, should
hopefully make this possible.
Consider making Path2D the only way to render paths with
PaintRenderingContext2D
--------------------------------------------------------
Github: https://github.com/w3c/css-houdini-drafts/issues/348
iank: This was brought up by a Mozilla engineer.
nical: That would be me.
nical: Idea is that the way we want to evolve our rendering code
involves a lot of expensive preparation that goes into
making path into something we can render efficiently under
GPU.
nical: If we can do as much caching as possible, the better.
nical: In light of doing a new API, if we could privilege things
that are easier to optimize, like things that are retained,
it's better for us.
nical: If we don't expect to need to invalidate custom paint stuff
might not be that much of a problem.
iank: Proposal was to drop the lineTo APIs and stuff.
nical: Force people to use path objects so we can cache them.
dino: Can't cache them between calls.
dino: Not going to keep path object between calls.
dino: ...
dino: When draw comes, have to build the path every frame anyway.
nical: That wasn't my understanding, thought state was preserved.
iank: Can potentially cache things in class, but can't rely on
that cache existing.
iank: Could do ... and use as a cache key.
dino: At that point API doesn't matter.
dino: You would have an implementation cache, is this path the
same as I used last time? If so pull it out of the cache.
nical: I have a preference for being explicit about when things
expire from cache.
dino: There's no way to specify in the API whether you're going to
keep the path.
dino: Don't know whether you will reuse the path, whether need to
keep the path around
dino: Unless you use SVG for ...
nical: Thought class registered for paint would be stored between
invalidations.
nical: So if that's the case then the web author could store the
path objects in there.
nical: In that case, it's very easy for us to know when things
should be flushed out of the cache
nical: because it's the lifetime of the object that dictates that.
nical: Have pref towards doing this rather than heuristic.
till: That would be the case for this. ?? pressure would ..
dbaron: GC may well be too slow for that.
iank: Other reason why I prefer not to do that is that existing 2D
Path libraries rely on the path to the APIs being on the
context.
iank: A lot of them work fine with the paint API as is, wouldn't
want to put a barrier in front of authors to use the paint
API.
dino: Tessellation dependent on transformation.
dino: Just caching paths would be good, but also want to know the
scale, tessellation, etc.
dino: No reason to be so accurate if drawing at a tiny scale.
nical: My specific impl goal doesn't worry about scale.
dino: When you say store on the class, there's no API for storing.
iank: It's .foo
dino: If we were going to store the path, I think we'd have a
specific API for "please store this path".
iank: I think nical was saying that any new 2d path that's
created, it's cached as long as there's a strong reference
to it.
till: You'd have to say "I still want to use this object", if not
it gets discarded?
till: As long as you say "use this thing from previous frame" then
keep it.
dino: You do know you've used it because you've drawn it.
...
dino: Could do this without being explicit.
iank: Could get pretty far with heuristics.
till: But that is easier with path2d.
iank: We'd just build up the path again internally and compare to
previous paths.
dino: Conclusion is implementations can go a long way down this
path.
...
nical: Don't have a strong objection, just if we reboot an API,
should do something easier to optimize.
dino: Your request was to remove part of the API, ignoring why.
dino: I'd say that's pretty strong feedback.
dino: For actual reason, we think we could optimize paths without
removing that API.
RESOLVED: No change.
Remove alpha flag, in favour of a contextSettings flag?
-------------------------------------------------------
Github: https://github.com/w3c/css-houdini-drafts/issues/435
iank: I noticed recently that the alpha flag is a little silly and
not really future-proof.
iank: There's maybe some other arguments appearing here, e.g.
color space.
iank: We don't want to keep on adding flags to the class, maybe
makes sense to have a dictionary.
franremy: Couldn't you just add on top of alpha? Why make the
change?
iank: Mirrors better the getContext API.
iank: However, I'm quite fine keeping the static ????.
franremy: Not a preference, just wondering why changes.
surma: I think mirroring getContext is a good idea. Also see
getAlias call being useful here, so makes sense to add the
object.
iank: Do you have a better name than settings?
surma: options? :)
dino: We should reuse ... [looking stuff up]
iank: canvasContextCreationAttributes?
dino: Yeah, contextCreationAttributes.
dino: We know we're in a context, so creationAttributes.
dino: But we know its attributes so maybe just creation.
dino: I don't think we should use the word settings
dino: creationAttributions.
TabAtkins: Can you make it longer, please?
Rossen: canvasContextCreationAttributes.
TabAtkins: Yup, thanks.
iank: Let's do a twitter poll, and pick the most popular
surma: Just use contextAttributes. That's how MDN lists it for
getAttribute2D.
Rossen: Sounds like we're going with the object, calling it
contextAttributes.
Rossen: Which is nicely in MDN already.
Rossen: Opinions or objections?
RESOLVED: Object called contextAttributes
Consider adding property for expected rendered bitmap size
----------------------------------------------------------
Github: https://github.com/w3c/css-houdini-drafts/issues/436
flackr: So for supporting high-DPI displays or scenarios where
you're drawing to something rastered at a smaller scale or
higher because it's zoomed in.
flackr: Might be useful to devs to know what final size will be
flackr: So can make decisions about how much detail to draw, or
how thin hairlines should be.
flackr: There was something on canvas context called
rasterBackingScale, never fully standardized.
iank: Shipped in Safari at one point
flackr: matched device scale ratio.
flackr: Having this would let developer make decisions about
quality, maybe pick faster paths for thumbnail-size image.
flackr: Wouldn't have to give dev the final one, could just be an
approximation.
flackr: Increase cache coherency by caching just a few sets of
display lists.
nical: Does this mean you invalidate paint every time you zoom?
flackr: You don't give true value, could just use a threshold.
iank: What we noticed is that everything inside the Paint API is
in CSS pixels.
iank: We had people internally trying to draw borders and couldn't
get the alignment right, wanted to be *on* physical pixels.
iank: For a lot of cases this isn't an issue, but doing border
type stuff it is.
flackr: So could be an additional value on canvasContext, could be
another value on paint context.
dbaron: Is there a reason that UA invalidate at some point?
dbaron: I guess I'm thinking about if a UA might want to use to
back their canvas by a buffer of drawing commands rather
than a bitmap, might be less need to rerasterize as you
scale.
dbaron: But might end up with web depending on the fact that
there's rerasterizing every so often
dbaron: because people are trying to draw device px -sized borders.
dbaron: Would be hard to switch to graphics commands that have no
need to rereasterize.
dbaron: Maybe detect whether this property has access, rerasterize
as needed.
iank: Also could request with a settings flag, I would like to
know what the backing style is.
scribe: dbaron
fantasai: A little concerned if you have access to this only in
this API and not elsewhere
fantasai: e.g., media queries, you'd want this information for
showing detail on an SVG. That's been brought up.
fantasai: If you can do that in paint worklet but not
declaratively in SVG...
iank: Not an issue for canvas today because people typically
inspect the devicePixelRatio property on window.
fantasai: That doesn't respond to zoom, though.
flackr: This doesn't necessarily have to (?)
fantasai: It responds to layout-affecting zoom, but not graphical
zoom.
dino: You couldn't get this (hairline) through normal CSS -- why
do you want to add it here?
scribe: fantasai
flackr: Where this comes up is we take the CSS sizes and align
them to pixel boundaries in some of our rasterization code
flackr: But as a developer, if you're writing custom paint for
this thing, we don't know if you want to draw between
pixel boundaries or do you want to snap to pixel
boundaries.
dino: I would sort of think, too bad, you've gone to this API with
custom drawing. You custom draw, you don't get the smarts of
the browser.
flackr: But then custom drawn stuff is inferior to the browser.
dino: It's inferior because you have less knowledge of the context.
dino: You don't get this with canvas.
flackr: You can do it in canvas already.
fantasai: Browser zoom.
flackr: Assume we do this only for layout zoom, then, not for
browser zoom
dino: Then why not query the device-pixel-ratio?
dino: I'd be fine with exposing that.
dino: I'd be concerned about exposing rasterization.
dino: Sometimes not needed to rasterize.
dino: Let's just expose device-pixel-ratio.
iank: I'd be ok with that
dino: Now suppose you always snap corner of canvas to pixel
boundaries.
dino: Not going to be undone by their own smarts if browser is
doing something smart.
dino: So what's the equivalent window in worklet?
flackr: So this solves the common case, rendering on high DPI
device nicely.
flackr: May not matter, but doesn't solve case of layout size
being changed by some ancestor scale.
Myles: Regular canvas already has that problem.
flackr: I think that's probably fine.
iank: So we'll need to work out what the best API is, either pass
as additional argument maybe among paint size object /
context
iank: or we could put it on the paint worklet global scope
iank: window.devicePixelRatio
iank: With requirement that when this value changes, they need to
rerun all the paint functions.
flackr: Not sure you need that requirement.
eae: Move to different screen, might lose quality.
dino: At that point you're painting again anyway.
dino: Don't need to spec that requirement, because you're
invalidating.
iank: Is a bit backwards from [canvas?]
iank: You create a canvas bigger than native size and then scale
it down.
dino: You say canvas width is CSSStyleWidth x devicePixelRatio.
iank: So maybe say give me the canvas scaled up to the device
pixel ratio instead?
dino: They have to do the scale manually.
iank: We give them the canvas in CSS Pixels.
dino: And usually people multiply canvas by devicePixelRatio to
get device-pixel-sized canvas.
iank: So maybe we should give a flag that gives them the device
pixel sized canvas.
eae: Why not use device pixel by default?
iank: People like drawing in CSS pixel space, because don't get
something weirdly small by default on highDPI devices.
...
dino: If you want to talk in small pixels...
dino: When you start painting, you assume you draw in CSS pixel
land, and when you want to draw at device pixels you scale
by DPR.
dino: ...
iank: Concerned about JS downscaling.
iank: Dino was asking why not always use CSS px and devs use DPR.
iank: My concern was about introducing rounding errors.
dino: DPR is in the range of .5 to 10, so not a huge range of
rounding.
Myles: When you multiply float by 2 or half or something, you're
fine. You'd have to have really big numbers before you
start having errors on the order of a pixel.
iank: Your version is you get a bitmap in CSS size, so you scale
1/r and I was saying we give it to you in the device pixel
size.
dino: I think mine makes sense because if you were doing in canvas
land, you'd get CSS pixels.
dino: You'd have to be explicit and say I want more pixels.
iank: My version matches canvasland a bit, because that's
implicitly what we do.
iank: Get the canvas in a larger size.
...
iank: You say explicitly, I want device pixels if this boolean is
true
iank: and the canvas is larger by the DPR.
dino: Are you actually making a mapping store for this?
dino: You're not actually creating a backing store, saying that
.5px will give author a solid hairline
dino: If iI'm at DPR=2, I can be pretty sure that .5px will be a
hairline.
[...]
Rossen: All of these paints are pre-transform paints.
Rossen: Going back to original motivation, you were talking about
when you zoom and you have transforms etc.
Rossen: Was concerned you were trying handle level of detail for
different optical scaling.
Rossen: Although this is a noble goal, I think it's going to be
very tricky to get right.
Rossen: Especially offsetting this to paint API.
Rossen: But when the problem resolved down to just accounting for
dpi, that's fine.
Rossen: I think that would be enough, and the hairline would
resolve.
Rossen: I think overall if we only gave DPR it's fine.
iank: Preference on exposing this as downscaling or upscaling?
dino: It would be really weird if your custom paint was a 1-line
"fill the entire box", you have to scale it by two.
dino: You should just say "fill the box"
dino: If you explicitly ask for the DPR
dino: Why would you want every bit of code to put context.scale?
dino: Context is the same every frame, don't need to do it each
time.
iank: It's the same number of lines of code each way.
iank: Does someone else have an opinion?
dino: Would be weird to say "this is what you have to do in every
paint".
dino: If you want to paint a hairline, you need to know, but
otherwise don't.
Rossen: This is why don't want to resolve level of detail.
Rossen: Keep adding details and additional details, that's very
different from.
Rossen: At the end of the day want to draw one pixel line.
flackr: My fault for filing an overly broad issue.
flackr: Where it came up was DPR problem
flackr: I think it's reasonable to pass that down.
iank: We had some bugs with painting from CSS API, but we can see
how this works and do dino's proposal and see how that works.
dino: So resolution would be, same value for DPR from normal
context would be exposed to the paint worklet.
iank: Or on the ? or somewhere. TBD.
dino: And effectively that's all.
iank: Might be better in input, because then invalidation is
clearer.
dino: Not necessarily that it's been invalidated, you're being
called to draw again.
Rossen: If the device-pixel-ratio is the only thing that changes
then you don't have to redraw.
iank: OK, I'm fine with exposing on global scope.
flackr: That would be my preference for consistency.
iank: Problem with worklets is we don't have a self object
iank: That may be fine
iank: window or self.dpr?
iank: OK, I'll talk it through with myself.
iank: I'm fine.
fantasai: So since we're exposing device-pixel-ratio, are there
other media queries that we want to expose here, like
color-gamut?
dino: On the main thread, would say I want to create a worklet
that operates in this color space.
iank: registerPaint, give me this paint worklet function, operates
in this color space.
dino: Maybe that's answer to high contrast, do it at creation
time, then need to have a listener in the main thread and
invalidate manually? That's maybe okay as well
dino: I think answer to fantasai's question is that there's
nothing missing, might be odd to tear down the worklet and
rebuild with a new MQ value.
jack: If you drag window from one monitor to another, would need
to tear down all worklets?
dino: Just the one affected
jack: For DPR it will just happen?
dino: ...
dino: fantasai's question was about what other other MQ values.
franremy: Set it onto a custom property.
Myles: If you drag from one monitor to another, could change color
space.
fantasai: Concern is, if dealing with DPR one way why inconsistent
about how to handle other MQs?
dino: DPR is special.
* fantasai isn't convinced
Myles: All of them will be available, but some will have different
lifetimes.
fantasai: Yes, but why should only one MQ be available to the
paint worklet, and the others need to be passed through
as arguments and worklets torn down and rebuilt through
a listener if they happen to change?
iank: If you wanted to write a paint worklet for device width,
would have to write a lot of listeners and recreate the
worklets.
dino: Why would you have a custom paint ...
iank: Can do it with a custom property.
iank: The paint worklet is registered to set of properties, will
invalidate when one of them changes.
iank: So could set the MQs you care about into a custom property
that's passed to the paint worklet.
franremy: E.g. might want to listen to reduce-motion.
RESOLVED: Add devicePixelRatio to canvasContext, other MQs can be
accessed via custom properties
<br type=lunch>
Publication/Shipping
--------------------
Rossen: Wanted to go around and ask for impl interest.
Blink shipping under experimental web platform features flag.
iank: We are currently implementing the two global scopes strategy
and switching them every X paint calls.
flackr: HighDPI issue was one of the last things on our list.
iank: We'd be ready to ship in a few weeks to a few months.
fantasai: Do you think the spec would be ready for CR at that
point?
iank: Yes
jet: We've started impl, got front-end scripting part in, but back
end rasterizer is blocked on us switching rasterizer back
ends.
jack: Servo has an impl of this that I landed a couple months ago,
even support speculative execution of paint calls.
jack: It passes a fair number of tests, but don't have TypedOM so
a lot of tests don't pass atm.
RESOLVED: Republish Paint API spec, announce intent to transition
to CR and request last round of review feedback
Received on Sunday, 27 August 2017 18:33:13 UTC