[Houdini] Minutes Paris F2F 2017-08-01 Part II: CSS Properties & Values, Custom Paint

   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


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
  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


  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
  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

  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
  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
  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
  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
  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

  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
  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
  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

  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
  Rossen: Sounds like we're going with the object, calling it
  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
  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
  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
  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
  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
  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 /
  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

  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
  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
  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
  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

  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
  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
  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
  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
  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
  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
  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
  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
  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>


  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
  iank: Yes

  jet: We've started impl, got front-end scripting part in, but back
       end rasterizer is blocked on us switching rasterizer back

  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