- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:44:37 -0400
- To: public-houdini@w3.org
Next F2F Meeting
----------------
- RESOLVED: Meeting 30 and 31 January in Sydney.
- RESOLVED: Meet for a half day at TPAC during plenary day
Custom Paint
------------
- One of the main issues remaining is if the spec should re-use
the existing canvas rendering 2D which has a lot of
unnecessary properties or create a new context.
- Most people thought there should be no readback.
- The buttons on http://materializecss.com/ were brought up as a
use-case that this spec should make easier to do.
- There is an open question as to how to deal with
box-decoration-break: slice
- Another open issue is how to deal with a paint that happens to
be an image.
- There should be an examples to show that randomness needs to be
in a property that's an input to ensure you get the callback
once for each heading with a different image and that the
callback needs to be consistent about what results from a
particular custom property value since the callback might get
called multiple times for various forms of redrawing.
- It was thought the spec should allow, but not require, backing
stores.
- The visual overflow should do a callback right after it styles
to do the tree walk.
- The inability to use intrinsic size for border-image will be
marked as an issue.
- Allowing 3D was briefly discussed, but several people felt it
was likely too complex to be part of the first version of the
spec.
- Another outstanding issue is if you stretch do you want to
rescale or do you want to know your new geometry.
- In some future level of the spec there should be a mechanism to
create new rendering contexts.
- If a paint function throws an error in the middle, a blank image
with no dimensions will should (hooking into the existing
behavior of CSS Image)
- Long running paints should be handled in the same manner to long
running JavaScript.
- For version 1 of the spec doing full invalidation is fine.
- RESOLVED: FPWD for Custom Paint (which will include the feedback
from today and more examples)
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Rick Byers
Tantek Çelik
Dave Cramer
Rob Flack
Simon Fraser
Dael Jackson
Dean Jackson
Brian Kardell (phone)
Ian Kilpatrick
Chris Lilley
Peter Linss
Cameron McCormack
Simon Pieters
Liam Quin
François Remy
Florian Rivoal
Simon Sapin
Elliott Sprehn
Alan Stearns
Shane Stephens
Ojan Vafai
Lea Verou
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Daniel Glazman
agenda: https://wiki.css-Houdini.org/planning/paris-2015?&#agenda
scribe: dael
Next F2F Meeting
----------------
Rossen: Good morning, everyone.
Rossen: I don't think we have a next meeting planned. We mentioned
briefly we might want to do Sydney. There's TPAC in
between.
dauwhe: TPAC is iffy because people have tickets.
shane: Let me check into space for Sydney. It's a bit iffy because
SVG is meeting.
plinss: Last time we talked SVG was after CSS and Houdini was
before.
shane: I have that week and the weekend before and after blocked
out. We can't overlap because there's only one room.
Rossen: heycam what's on your calendar.
heycam: I'm not sure.
shane: Let me check on dates.
Rossen: From what I'm hearing people are concerned about TPAC.
What if we could find non-CSS dates?
TabAtkins: I'm down with that if we need it. Do we need something
in 2 months or give ourselves 6 months?
shane: This event felt like a forcing function so I suspect if we
decide we'll next meet in Sydney we won't see work until
close to then, like happened for this. TPAC is a short term
target.
Rossen: That's true, but is that the only way to have a forcing
function?
ojan: I want the forcing function, but don't think I can make it
to TPAC.
Florian: The Sunday before TPAC we have the CSS Japanese Community
Meet-Up.
shane: Could we do a half day?
gregwhitworth: I think we should use the plenary day as a half day.
TabAtkins: So those of us there will meet up and talk and it's not
a big deal if you can't be there.
dauwhe: Sounds good to me.
TabAtkins: Use part of the plenary day to do some spec review.
dino: Okay.
Florian: Like two time slots.
dino: So we're not getting a meeting room, we'll just use the
plenary. OK
liam: Keeping momentum is good.
Rossen: Sounds like a half day on the plenary day of TPAC is good.
Rossen: How about Sydney? The weekend before or after?
heycam: SVG was the 4-6. Is that Thursday to Saturday?
Rossen: And CSS is the 1st?
plinss: Through 3rd.
Rossen: So for Houdini we only have 30 and 31 Jan which is a Sat.
and Sun.
ojan: Could we do 28 and 29 Jan?
shane: Depends on if I can get meeting rooms.
shane: We made it 30 and 31 to minimize time in Sydney to reduce
travel costs. Florian were you one that asked for that?
Florian: I may have been, but I'll be in Japan now.
TabAtkins: My travel cost is time spent away from home.
Rossen: Me too.
Rossen: If we did the weekend is that okay dino?
dino: It's okay. I'd prefer not weekend, but it seems like the
consensus is to minimize time.
shane: I'd prefer not weekend too, but I understand.
Rossen: Is anyone not able to make the weekend 30 and 31 January
in Sydney?
RESOLVED: Meeting 30 and 31 January in Sydney.
RESOLVED: Meet for a half day at TPAC during plenary day
Rossen: Do we need to plan anything ahead? I guess not
Custom Paint
------------
<iank> https://drafts.css-houdini.org/css-paint-api/
iank: What I was hoping was to get a discussion about author
current issues and if this is a good way to move forward. Do
people want a rough overview?
many: Yes.
iank: I'll skip to the example. What you get is inside one of
these Houdini workers you get a registered paint function.
This allows you to register a custom paint function, a list
of property dependencies, and a paint callback. This gives
you a canvas rendering context, just 2D, it gives you your
geometry of the fragment you're painting into and it gives
you a typed property map.
iank: This is how you use it. The image type in CSS is extended to
be image or paint now and this can accept the named function
and paints into the background image layout.
Rossen: Can you go over the context?
iank: This is one of the big issues. In the spec it raises canvas
rendering 2D, but it doesn't have any readback or other
methods that make no sense. Things like drawing focus rings.
The reason you can't get data is it works in an intermediate
mode. There's no retain on it, you have to paint every time.
iank: This is one of the big issues. There's three ways of looking.
We can re-use the existing canvas rendering 2D, but it has
all the functions that make no sense. The better option is
to create a new canvas rendering context that's write-only
canvas rendering that takes a strict subset.
iank: Do people have thoughts on which is right?
smfr: The write-only one can be a base class.
iank: Yeah. We can do a parse interface and just mix it in. The
base class might be interesting for webcompat.
dbaron: Are there any similarities to the workers on canvas?
iank: I think they explicitly allow grabbing the image out.
dbaron: I would have thought they wouldn't have had the various
a11y things.
iank: That's true. They explicitly want the readback.
esprehn: I think the goal was to split canvas into a series of
partial interfaces.
Florian: Why no readback?
iank: It doesn't allow for a bunch of optimizations. So things
like being able to, if you have a long page, the UI can opt
to through the previous data; if there's readback you can't.
smfr: And you may want to not store this as pixels.
iank: So it sounds like we should talk to the canvas folks.
dino: I don't think there is canvas folks.
iank: Yeah. We've got our subset. Anyone opposed?
Florian: On the syntax side, I'm not sure which I prefer. That
paint function which isn't what you would have in a
normal CSS design thing, you don't have the magic there.
If you have a separate property you can have a trigger
and then you need a double hook.
Florian: On one hand this is weird, on the other hand I'm not sure
if we want to expose the broadest place if it's the
background or cursor and that long list looks bad.
iank: So you're saying a more idiomatic way would be verified
reference of the layout property.
smfr: This is similar to what we do in canvas. I think it's okay.
I'm not sure paint is the right thing.
iank: I'm fine with bikeshedding.
Florian: The way the syntax is described here is fine, but you're
having a double dependency here and so you can't have a
background circle property that would trigger the circles
being drawn, you also need the paint function.
shane: I think this is a trade off. On one hand you have the
double dependency, but this lets us slot into the existing
way CSS does images and you can also stack these things. So
I think it's worth it.
TabAtkins: And if you didn't want to write the background image
you can register an apply hook to the property, you can
write it yourself as the only controller.
Florian: So the current proposal looks like the best thing, but
I'm still iffy.
esprehn: The only proposal today that has what you're explaining
is inheritance.
Florian: Another comment, you list the dependency property, you
probably need to specify you're depending on the used
value. That's because if you're depending on width you
want to call again if the used value is called.
TabAtkins: Yeah.
shane: The properties don't have to be used value.
Florian: They have to be actual.
iank: When your layout changes, your paint function will get
called if your geometry or your layout gets changed.
TabAtkins: There's no explicit width or height dependency. What
you actually want is not width or height, you may be
using this in a list marker. You just want to know if
the size has changed.
Florian: We should take it as late as possible in the chain.
TabAtkins: Given that it's late in the chain anyway, that's fine.
TabAtkins: Are we planning to do argumented in this level?
TabAtkins: This won't do let's do a custom conic gradient.
iank: One thing this doesn't cover is how to do conic gradient.
This doesn't allow you to do your own custom gradient.
smfr: Can I do the same paint function on different elements with
different sizes on mobile?
iank: Yes. It registers one function, it may be used 50 times.
heycam: What happens when you have something split over lines.
There's one that controls how background image splits?
iank: It'll get called twice for each fragment. This is an open
issue. One you could expose the geometry you are and your
sibling fragments.
TabAtkins: That brings up another question. This interaction with
box-decoration-break, if you're cloning it's obvious
each fragment should get a different call. If slicing
it makes sense to draw into the combined size and then
slice.
smfr: I'd argue it would be better if this is agnostic about
box-decoration-break. Authors may want to do special
behavior with splitting and broken.
TabAtkins: I'm not sure I agree. I'd like box-decoration-break to
work automatically for now.
dbaron: If you got a separate callback for the cloning one...What
if that had enough information to do whatever you want. If
box-decoration-break is slice it would automatically break
it up. If you want to clone it gives you the number of
boxes and you can do something else there. Is the default
slice?
TabAtkins: [tentative yes]
<dbaron> The idea was that box-decoration-break:slice would mean
the UA would give a canvas covering the whole thing and
auto-slice it up; box-decoration-break: clone would mean
multiple calls to the paint callback for each fragment,
with the fragment number, which would allow the callback
to do whatever arbitrary behavior it wanted.
iank: So we need to expose all the information of the fragments.
Rossen: Or enough of the previous fragments.
smfr: Level one might be good for just boxes.
Rossen: If it fragments this does work?
smfr: Weeeeelllllll...
iank: A simple thing we can do is which edge of my box was
connected to my previous fragment as a simple version 1.
Rossen: Is there any other state you need? Like if background is
active?
TabAtkins: For now without arguments you just register the paint
style.
dino: You don't need an argument you can just do a different
custom property.
TabAtkins: They are a different function, but only if you're
calling once per element.
franremy: The issue with using custom properties for arguments if
you want more than one gradient as background you're
screwed because you can't send arguments to each.
shane: I think we'd add that in a future level.
TabAtkins: This gives you all the power in webkit-canvas and most
of the element function.
gregwhitworth: When you said they're meaningful consumption, we'd
like real use cases.
iank: A couple we would use internally is the material design
button. They went through lots of iterations to get that
performant.
TabAtkins: Is everyone familiar with the button ripple in our
material design?
iank: [pulls up http://materializecss.com/] There's a ripple
following out from when I click on the button. The DOM
structure is 'interesting'
iank: That's the kind of thing.
heycam: You're saying that's possible at the moment or you'd like
to make it possible?
iank: It's possible, but we'd like to make it easier and more
performant.
Rossen: In this example your geometry isn't changing? What is
triggering the additional callback when geometry isn't
changing?
iank: As an input you'd have a custom property that is a list of
where your click originated and a time and animate on the
radius.
dino: You'd have a set of custom prop when the user clicks, then a
transform, okay, I get it.
smfr: Can you get time?
iank: There isn't in this. If you wanted one you would create a
custom property and throw a web animation at it.
smfr: So the geometry or custom property needs to change.
iank: Yeah.
ojan: This is similar to how the underlying system works.
TabAtkins: In the worst case you could have a dummy custom
property you have to tickle to change, but if that
becomes a problem we can change.
shane: We don't want people register sensitivity to time.
iank: As soon as time is an input we'll get wildly differing UI
behavior.
heycam: That's what you'll get anyway. What's the difference
between that and having a time passed in. I was thinking
of creating a custom property that represents the time.
shane: You can do that, but there's better way to do that.
iank: We don't want to paint indefinitely into time.
TabAtkins: You could, but only on an animation that's set to
infinite.
shane: And that's under the control of the animation system.
shane: I'd like to suggest we take this to FPWD.
Rossen: Thoughts?
smfr: I think people will want to draw images. People talk about
wanting custom border radius, so adding images is important.
iank: I think that's part of the typed OM spec. It would have if
this image has loaded and you could also have an image
bitmap.
TabAtkins: That implies you're passing in via a custom property.
dino: You might want to use a mask image.
shane: Once we have function arguments for paint.
dino: I want it where I can find a function.
TabAtkins: You want a paint that happens to be an image.
shane: You have to get it into the context somehow.
TabAtkins: How do we get it in there is the issue.
dino: The paint global scope...you could have some kind of a pair
function.
rbyers: This goes back to the debate about the state. You'll have
life cycle.
franremy: When you load the image previously it will possibly not
be ready to paint. That's not something in the draft.
heycam: In the worst case you can encode the URL. Update the
script that says run worker and update that.
iank: We'll take that as an issue.
dino: Having some kind of initialization would be useful.
smfr: There may be extensive set up.
TabAtkins: And you want to be able to cache for painting and
register that. Any relatively expensive thing you don't
want to recompute every call
iank: This has a paint callback and there's an issue to make this
class paste instead. This will be fairly easy to do in the
constructor.
ojan: I think that syntax gets you multiple callbacks.
smfr: Second issue is that if you register this on multiple
elements you get called for each elements. I don't want to
use more backing store than webkit-canvas so I want to be
able to store for elements with the same geometry. I want to
say that I don't want to call this more than once for items
with the same geometry.
TabAtkins: Could that be controllable? I've thought of use cases
where I'd like every heading to look a bit different.
In the default it would register the same. But we
should have an opt in for 'no, never mind'.
ojan: Would those be different property?
TabAtkins: So I want a fancy, unique drawing on each heading.
rbyers: Then you have to do that with custom properties with a
different value.
shane: You can't have both not random and not specific.
TabAtkins: Okay. I get you. Never mind.
ojan: The main open question is if the spec should say
implementors are required to called once or allowed to call
once.
iank: I think, calling how ever much you want is fine.
ojan: I was going toward the opposite.
TabAtkins: If you want randomness you have to be able to control
how many times you are called.
Florian: If you want the painting of a background to be influenced
by the content of the element, how do we extend this to
allow that?
esprehn: There are properties that instead from only accepting CSS
you an accept more complex values. You have to be
explicit on what you depend on.
Florian: We have the element function, how do we track that it
changed?
TabAtkins: Given security concerns that won't be exposable. If you
want to do something like text-shadow, some of those
move into the user land. Shaders was something that
everyone thought was too complex for now. Nothing
conceptually against it, but it's hard implementation-
wise.
dbaron: It seems like a useful example to put in the spec where
there is a different thing for each heading and to explain
that you have to be consistent about painting each time
you get the callback and that you have to define custom
property to do it.
TabAtkins: Can we see randomness in JS?
several: nope.
<dbaron> that example helps clarify both that the randomness needs
to be in a property that's an input to ensure you get the
callback once for each heading with a different image,
and that the callback needs to be consistent about what
results from a particular custom property value since the
callback might get called multiple times for various
forms of redrawing.
esprehn: The API, you shouldn't have to construct backing stores.
smfr: The implementation may use back store because that's what
they use.
shane: It shouldn't be prescriptive.
esprehn: But it's open for optimization.
smfr: One other concern I see the spec addresses.
iank: So the visual overflow is not how CSS works today. Do people
think that the visual overflow saying statically you have
20px on each side or should it react to style?
dino: It has to react to style.
iank: Yep. The question is how do we do that?
heycam: A second callback that returns out.
iank: So in the class base structure you have a computed 'my
overflow' by default.
iank: The only problem is that when you're working out when you
need to paint...it might be fine...When you're walking down
you need to know ahead of time what your visual overflow
rectangle is.
dino: It still should be dependent.
iank: So we call right after it styles to do the tree walk. We'll
see if we can implement that.
smfr: One thing I'd like the spec to say is what the origin of the
context is when you do the call back. It's expecting it to
be the top left.
iank: At the overflow or logical coordinates?
smfr: Logical.
iank: And you paint your overflow into negative space. Yep.
smfr: Something else...let's say you want to use this for
border-image, I don't think you can give an intrinsic size.
You get sized to the element plus the overflow. So you
couldn't optimize your backing store by doing a small paint.
iank: Yeah. That's something I've thought about. With border-image
it makes you declare at the time.
dino: So the set up could pass in what size it wants. I'm going to
produce and output of 50x50.
iank: And we can drop border-image for the first version.
smfr: I think that's one of the most useful cases.
iank: I'll drop that as an issue.
dino: Are we sure 2D is enough?
iank: For version 1.
dino: One thing is people want to do really fancy painting.
ojan: We have examples of that, definitely.
iank: For version 1 I want to keep this simple and punt 3D to
version 2.
ojan: I shared your feeling for why not and someone convinced me
there is a lot of complexity.
iank: How do you put custom into WebGL with 3D and how does
invalidation work?
dino: I don't think it's version 1.
iank: We can always pull it in when we get stable.
TabAtkins: Is there a practical limit on number of 3D per page?
dino: Very much so. Depending on what you're trying to accomplish
you'd want one shared context that draws a lot of things.
That's what canvas workers are trying to get to. If you can
draw once and using it in multiple places, that's better.
esprehn: Sounds like there's an action to bring images into the
spec.
smfr: That's one side. If you were able to declare an intrinsic
size you can treat it as a sprite sheet.
TabAtkins: Yes, we do need intrinsic size.
dino: I think this is what we said before. If you can spec what
your output size and custom paint will be.
TabAtkins: There's the three dimensions, width, height, aspect
ratio, and we need to deal with those.
TabAtkins: I suspect the paint class itself is fine.
smfr: You need the size before you call the paint callback.
ojan: Is the thing you put in like 100px or a function of the
paint callback?
dino: There's cases for both.
TabAtkins: There are. We could set up a default, but maybe we
could have a way to set it. Maybe that's version 2.
Having a static size you set might be version 1.
astearns: With background-repeat you might want to get what the
size of a whole background will be and then modify the
tile you're going to paint to be able to multiple to
fill without clipping.
TabAtkins: Background-size has that. So we'll pass that in as the
canvas size.
dino: Background-size has this? I think astearns is saying he
wants 1, 2, 3...
astearns: I might want it to decide the size.
TabAtkins: background-repeat: round.
dino: You won't be pixel perfect when stretching.
TabAtkins: Do you want to rescale or do you want to know your new
geometry. I don't know which we want to default.
TabAtkins: If you set 20x20 and someone sets 100x100, do you want
us to lie and say 20x20?
dino: Yeah.
TabAtkins: I think that's an issue.
TabAtkins: When CSS scales you do you get told that or told your
original size.
SimonSapin: Is there a reason to paint other than device pixels?
TabAtkins: Simplicity. If you expect a 20x20, you might not write
code for a 700x700 canvase.
astearns: I'm a little concerned with making a new image or paint
type that has to be added.
TabAtkins: It should be image.
iank: Cursor.
TabAtkins: If that's a problem. Cursor can disallow custom
painting.
Florian: What's wrong with it?
rbyers: Yeah, why not?
TabAtkins: I don't know what the issue is.
TabAtkins: If it's hard I believe you, I want to know why.
rbyers: We'd only call it once.
iank: Unless you invalidate.
TabAtkins: Cursor allows you to ignore the animated images, so we
can say you only call once.
gregwhitworth: But if you only call once and you can provide a
png, why do it?
esprehn: This doesn't sound version 1.
TabAtkins: Yeah. I'd like to discuss privately because I don't
understand.
esprehn: I mean, maybe punt it forever.
iank: I'll take it as an issue.
iank: So this should be part of image and we'll discuss what
happens with cursor later.
franremy: Can you actually ask the engine to cache whatever
painting you've made? If you have a looping animation
you want to draw everything one time and re-use.
iank: We were discussing that a couple days ago. This is the read,
modify, write use case. I don't think it should be level 1,
but one easy way to provide this is if you say you want to
you get an additional argument that's your last bitmap
shane: franremy is looking for multiple images.
smfr: Sprite sheet.
franremy: Where do you store it?
TabAtkins: Can we load a cached image, can we load a drawing?
esprehn: I think that would be necessary because a lot of canvas
features are such that you can draw a canvas to a new
canvas. So such a feature needs to exist and you can do
new paint canvas and store it.
iank: It sounds like, then, create a way to create new rendering
contexts.
iank: Take that as an issue for a future spec.
smfr: I don't think spec says it, but the initial state of this
context should be said.
iank: That's an issue in github.
iank: Just going to read through and see if there are other big
use cases.
iank: Issue 8 I'd like feedback. If for some reason your paint
function throws an error in the middle, what happens? Do you
output blank or what you've processed?
heycam: I think painting what you got up to is more flexible.
smfr: You can debug.
heycam: If you're immediately applying those paints, it lets you
have the flexibility.
TabAtkins: CSS images has an invalid image that is transparent
with no dimensions. We can link to that.
Rossen: Which is the equivalent of not painting.
TabAtkins: Yes, but hooking spec-ese into it is good.
heycam: I suppose that this is in a separate thread so it won't
immediately paint.
iank: Yeah.
iank: Anyone opposed to partial commands?
TabAtkins: I'm somewhat opposed. I'd prefer a whole image or none
so we can invoke fallback correctly.
shane: As a dev it's nice to see how far you've gotten.
TabAtkins: Whatever exception was thrown in the canvas, we can
surface that on the main thread.
esprehn: I'd prefer we don't paint partial commands.
shane: Not in the page, but if dev tools are open?
TabAtkins: I don't want to show partial because if anyone
implements image() it lets you paint a color if the
image is still invalid.
iank: Sounds like we do blank image.
smfr: Related, in these limited scripts the author can't do
console.log so some way to get an error out is fairly
important.
liam: Especially if the context is more restrictive.
esprehn: console.log is available to workers.
iank: I had consoles and could debug.
ojan: You need console logging and post something back to the main
thread.
iank: This goes into the isolated workers spec.
ojan: I get we have a solution, but it's a version 1 use case.
iank: There was a big thread about supporting partial invalidation
on canvases. I'm personally not in favor for it as version
1, but I'd like other feedback.
smfr: It doesn't seem necessary for version 1.
iank: Anyone opposed?
gregwhitworth: I think MaRakow had opinions.
Rossen: I'm the one who raised it, but as a version 1 solution we
discussed it and full invalidation is fine.
iank: In Sydney we talked about configuring a clipping a context
so we can pass filters and I think we punt that from this
level.
iank: So you can't say the global alpha for all your background.
Getting to that isn't this level.
iank: And then there's issue 3 about what should we be writing in
the spec where we've got things that are being nasty. I
think if it's valid code and a complicated paint we should
wait and paint it. But I'd like other opinions.
iank: We could also keep this issue for later.
iank: No opinions, awesome.
dino: I think we should wait to see.
iank: I think that's it for me. Anyone else?
smfr: Does this describe when paint callbacks get called?
iank: Basically this is section 2. Something becomes invalid when
the geometry or the computed style changes. When displayed
on the screen the UA has to request.
liam: Two editorial comments. One is you have an issue 18 or 19
about fallback.
liam: It would be nice to fill in the example showing how to
fallback to a static image.
liam: I don't know, but it may be worth a note on the a11y.
iank: Yeah. It's not a11y. I think this might help a11y because
people aren't creating unnecessary DOM structures.
smfr: Can you use custom fonts and set font style?
iank: I think you should be able to draw text, but I don't have a
good answer for how the fonts are resolved yet.
dino: I guess the font-size resolves? In the paint callback it
needs to know...it has to be dependent on the font-size
property?
smfr: What if you set font-style to 2em?
TabAtkins: Oh, this runs by necessity at least at used value time,
maybe after.
smfr: Are you resolving against the element? That breaks the
sharing.
dino: If in the canvas you say you want to draw text at 5em, what
do you resolve the em against?
esprehn: The default canvas is resolved against the default font.
iank: Sounds good.
dino: For the long running paints, do we need this to be different
than long running JS?
iank: I think we want the same behavior, yes.
iank: I think this will help in that sense because you'll be able
to attribute the long code to a specific paint function.
Rossen: Let's move on. So shane proposed FPWD for this.
smfr: This depends on custom prop, right?
shane: Not in a sense that...without having custom properties you
can install these now. It's banded with them, yes.
TabAtkins: You can install a null. With Typed OM you can install
non-null. With custom properties you can animate those.
We have nice gradated steps.
Rossen: Anyone opposed to publish FPWD?
dbaron: This includes the feedback from today?
Rossen: Yes.
RESOLVED: FPWD for Custom Paint (which will include the feedback
from today and more examples)
<break=10min>
Received on Friday, 16 October 2015 23:45:37 UTC