- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Mar 2015 14:24:35 -0500
- To: public-houdini@w3.org
Custom Paint
------------
- There was ample conversation about how this spec should be
constrained to provide maximum opportunities without
creating too much complexity or problems with complex
objects, like backgrounds that contain video.
- RESOLVED: shane, iank to start work on CSS Paint Module
Custom Layout
-------------
- There was a lot of concern addressed about making sure that the
properties in this module don't create loops or hangups, so
the editors will make sure to keep that in consideration as
they write the spec.
- Since this is such a large undertaking, it's also likely that it
will be handled in chunks instead of being solved all at
once.
- RESOLVED: gregwitworth, iank, TabAtkins, shane, roc, and Rossen
to start work on CSS Layout Module
===== FULL MINUTES BELOW ======
Custom Paint
------------
Scribe: jet
Rossen: This afternoon's agenda:
Rossen: Custom paint, custom layout,
Rossen: Input extensions, async, threading, process.
Iank: [whiteboard]
<ChrisL> custom paint
https://c1.staticflickr.com/9/8061/8206144541_4843dd6445.jpg
Iank: Custom paint assumes invalidation e.g. custom properties.
iank: Properties that invalidate paint (not layout) should have
paint callbacks.
iank: With custom context to be safe,
iank: To not leave layout in an inconsistent state,
iank: There's roughly have 3 areas to override:
1. on BG layer
2. on content
3. on outline (potentially)
dino: Does this include children?
iank: Not sure.
roc: There's an argument to be able to modify paint for your
children, e.g. for effects.
roc: We should constrain scope.
iank: We should constrain to just your paint (not children).
iank: For example in a function(ctx, style) get a canvas context
and style information.
iank: ctx.clipPath = path
iank: ctx.paint(self)
krit: Can we cover the different paint phases?
iank: Most effects are covered, per canvas.
iank: Or we just use the background layer depending on how
fine-grained.
krit: What are the use cases for custom paint?
iank: An example is Google material design.
iank: It draws custom shadows on buttons.
iank: Currently we add DOM nodes to get this effect.
krit: Why do that? Chrome can already draw a canvas element as a
background.
iank: [Projects demo on screen]
<iank> http://www.polymer-project.org/components/paper-button/demo.html
iank: We can't do this easily with DOM elements today, and need
script for that.
iank: When it was first designed, button effects had gradients.
dino: You already have the context, should be able to set what you
want, like WebVR.
dino: You need to know the backing store to cover the element and
effect.
dino: It needs more knobs on the API.
esprehn: Currently it's a read-only API no backing store.
dino: It may need to be able to get readback (eg from WebGL).
iank: For example, for getting 3D canvas?
dino: Don't limit it to 2D API.
dino: We might need a retained model like SVG.
dino: Can do similar effects with SVG as input to custom paint.
esprehn: With 2D canvas you can address a lot of use cases.
esprehn: We can do 3D and displayList later.
iank: Initially, specify 2D context, leave it open for later.
krit: How is it different from BG canvas feature?
iank: There's problems with webkit BG canvas.
iank: You can't use the default canvas.
roc: I don't want to introduce new rendering, just modify existing
parts.
esprehn: Want to call in before and after paint.
esprehn: [shows physics effect on whiteboard]
iank: You need a known width/height before use for canvas.
iank: With this proposed API you can get dimensions at paint time.
iank: Say width is animating, you can do effects without
synchronous layout flush.
roc: You can apply an effect, draw yourself, but if content is
complicated, layerization gets messed up.
roc: Such as video on the background, you call drawSelf( ) it
draws the button and video, but now layer decisions get
complicated.
esprehn: You'll need to opt into staying on top or below other
content to force layerization.
roc: If there's clipping, you need to wrap your content with
different options.
esprehn: You need some way to push a clippath or opacity layer.
esprehn: Probably you'd want a surface area that's closer to a
traditional drawing API.
esprehn: Or use a display list.
krit: Are the 3 context options combine-able?
iank: No, one per paint phase.
iank: Depending on what's useful for authors.
dino: If you're doing something with video, the compositor handles
video paint.
krit: Can we handle certain phases first?
roc: How important is it to modify content now?
esprehn: Can't mask to arbitrary shapes.
roc: You can do it with SVG masks.
esprehn: You can't do it without layout flush.
roc: Which use case?
esprehn: I want to mask descendants based on current size.
esprehn: And to scale the effect as size changes.
roc: Is that OK to lag? Concern is trying to apply custom effects
to the contents of an element that aren't accessible easily.
dino: With video, you'd get a lag unless we do compositor tricks.
roc: It ramps up the complexity for edge cases.
esprehn: Just for clippath?
roc: You can get into very complicated states with multiple
transforms, or not draw at all, or call drawSelf() twice.
iank: drawSelf() is constrained before() or after() only.
roc: The complexity is added by masks, etc.
shane: It seems pretty standard to invoke custom behavior before
or after a built-in context,
esprehn: Add clippath, opacity, transforms with API.
dino: 3D API's allow hooks into different phases of the rendering
iank: Mangle with a limited subset within API.
dino: Does this happen before filters and xforms?
shane: Filters should apply.
krit: Filters affect all operations.
dino: You won't be able to override a CSS clippath with custom
paint.
iank: That should be fine.
shane: Why can't we expose clippath?
dino: You shouldn't be able to modify the clippath passed into you.
shane: You can modify local clippaths.
dino: I'm worried about restrictions per context,
dino: To avoid touching the backing store.
shane: We can add other contexts later.
roc: What kinds of restrictions do we want in the JS environment?
iank: Initially, just get the context, read the style, get the
fragment size.
roc: Do you have persistent global state between paints?
iank: The style object passes in state.
esprehn: The features are coupled with custom CSS properties (eg.
to cover animated physics based on buttonDown).
esprehn: [whiteboard]
iank: State comes from style.
roc: We won't need to count paints without global state.
roc: How to send/receive messages?
iank: Via the style object.
dino: How about images?
iank: Use an arrayBuffer with the image data.
roc: Use transferables/structured clones in the API.
dino: What's in the style object?
iank: Either all computed style or just what relates to paint.
iank: The author can specify which properties they want.
esprehn: You should use the current geometry, not supplied sizes.
roc: You need to have access to custom and built-in styles, it
might be good to share custom paint and custom layout
features.
esprehn: Except that not all layout causes paint.
<bkardell> It would be good to sketch out the process /
relationships of what we are talking about (all of them
I mean)
dino: You can specify what you want to invalidate paint.
dino: It looks a lot like CSS shaders.
dino: Are you allowed to control how long it should take to paint?
bkardell: It would be good to list what happens from parse to
layout to paint and show how to plug into the API.
esprehn: The specifications are intertwined.
esprehn: First, a spec on the JS execution (in limited context)
esprehn: Then specs on the layout and paint.
<bkardell> +1
krit: How do you prevent pixel leakage?
roc: How to prevent timing attacks?
dino: Limit out drawSelf()?
esprehn: webGL makes sense above or behind content.
krit: That would allow limited access to GL pixel data.
roc: Rendering to GL surfaces will be high overhead.
dino: I'm more worried about performance issues from usage.
Rossen: Any concerns re: SVG?
krit: We don't have z-ordered paint phases in SVG (yet)
ChrisL: Canvas is expected to work with SVG.
krit: SVG should be able to work as well.
Rossen: proposed resolution: shane, iank to work on Custom Paint
proposal (CSS Painting)
RESOLVED: shane, iank to work on CSS Paint Module
rbyers: Do we need an uber spec?
<bkardell> rbyers: at least a note
Custom Layout
-------------
shane: Custom Layout, callbacks like for paint,
shane: Are to read pieces of computed style that's targeted for
Layout.
shane: Filter the computed style to the pieces that are relevant
for Layout.
shane: This will depend on fragment tree spec.
shane: API needs to create such fragments.
dbaron: You want this to be separate from normal layout,
dbaron: With some new display type to invoke it.
dbaron: Callbacks will layout its children.
<bkardell> dbaron that's mostly what we discussed at edge,
<bkardell> Seems good.
TabAtkins: new display:--whatever would work.
dbaron: Mixing custom and built-in layout gets complex. A new
display type should avoid that.
shane: Restrictions should make this more implementable.
Rossen: Declaring an element to have custom layout should take
over built-in layout.
dbaron: Descendants that use built-in layouts should be OK.
dbaron: But don't let that happen with something like table
descendants that make anonymous boxes.
<dbaron> Just that using a different 'display' value is useful
because we have anonymous box construction rules that
deal with things like avoiding invalid combinations like
a display:table-row child of something arbitrary.
roc: What about fragmentation? Do we need to support braking, etc?
shane: Yes.
TabAtkins: We need to support printing, etc.
roc: Interoperable fragmentation/breaking API will be hard.
shane: We can make that call later.
roc: We could have a simpler API that doesn't provide for breaking
and a more complex API that does; that might be better for
authors anyway.
plinss: We should provide for breaking, doing so later may get
harder to add.
SteveZ: There's a use case for breaking: eg. MathML and text.
plinss: We break this out into smaller phases.
plinss: Don't put everything in one call.
plinss: For example, have a phase for sizing.
shane: Also, don't make engine-specific assumptions.
Rossen: How do you prevent hangs? Infinite loops?
Rossen: Custom layouts often create cycles.
Rossen: How to prevent that?
Rossen: Can't keep it to one iteration. eg 13 levels of recursion?
iank: Constrain things within phases?
roc: Are we OK with constraining to basic CSS (intrinsic width,
computed width, height calculations from children, etc.)
<bkardell> Seems ok - at least for now seems ok.
Rossen: Flexbox and grid already exceed the basic CSS box
calculation.
Rossen: We shouldn't create cycles, but flexbox gets that way
easily with custom layouts.
Rossen: Should we treat custom layout as fixed size?
iank: API will be used by framework developers.
roc: We need to prevent lockups even from iframe usage,
roc: Such as Facebook like buttons.
Rossen: Proposed resolution: greg, iank TabAtkins, shane, Rossen,
roc to start work on Custom CSS Layout.
krit: need use cases before API discussions
RESOLVED: gregwitworth, iank, TabAtkins, shane, roc, Rossen start
work on CSS Layout Module
[15 minute break]
Received on Tuesday, 3 March 2015 19:25:11 UTC