IRC log of fx on 2011-11-03

Timestamps are in UTC.

15:59:34 [RRSAgent]
RRSAgent has joined #fx
15:59:34 [RRSAgent]
logging to http://www.w3.org/2011/11/03-fx-irc
15:59:38 [heycam]
Zakim, this is SVG
15:59:38 [Zakim]
sorry, heycam, I do not see a conference named 'SVG' in progress or scheduled at this time
15:59:43 [heycam]
Zakim, room for 4?
15:59:44 [Zakim]
ok, heycam; conference Team_(fx)15:59Z scheduled with code 26631 (CONF1) for 60 minutes until 1659Z; however, please note that capacity is now overbooked
16:00:39 [heycam]
Zakim, code?
16:00:39 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
16:00:57 [Zakim]
Team_(fx)15:59Z has now started
16:00:59 [Zakim]
+tpac
16:01:46 [heycam]
cabanier, you can call in now ^
16:02:49 [jun]
jun has joined #fx
16:05:21 [Zakim]
+ +1.206.675.aaaa
16:05:23 [Zakim]
- +1.206.675.aaaa
16:05:23 [Zakim]
+ +1.206.675.aaaa
16:05:25 [cabanier]
thanks!
16:05:44 [plinss]
plinss has joined #fx
16:06:52 [cyril]
cyril has joined #fx
16:08:15 [TabAtkins_]
TabAtkins_ has joined #fx
16:09:27 [efidler]
efidler has joined #fx
16:09:47 [heycam]
RRSAgent, make minutes public
16:09:47 [RRSAgent]
I'm logging. I don't understand 'make minutes public', heycam. Try /msg RRSAgent help
16:09:55 [heycam]
RRSAgent, make minutes
16:09:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/03-fx-minutes.html heycam
16:10:54 [heycam]
RRSAgent, make log public
16:11:14 [heycam]
Meeting: FX Taskforce at TPAC 2011
16:11:14 [heycam]
Chair: Erik
16:11:15 [heycam]
Scribe: Cameron
16:11:17 [heycam]
ScribeNick: heycam
16:12:23 [ed]
RRSAgent, this meeting spans midnight
16:13:11 [shans_]
shans_ has joined #fx
16:13:13 [efidler]
efidler has joined #fx
16:13:46 [vhardy]
vhardy has joined #fx
16:14:11 [dino]
dino has joined #fx
16:14:14 [jen]
jen has joined #fx
16:14:20 [cyril]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
16:14:23 [heycam]
Topic: CSS Compositing
16:14:31 [Eric]
Eric has joined #fx
16:14:35 [vhardy]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
16:14:49 [smfr]
smfr has joined #fx
16:14:56 [heycam]
Zakim, who is on the call?
16:14:56 [Zakim]
On the phone I see tpac, +1.206.675.aaaa
16:15:15 [heycam]
ED: we have SVG Compositing, which defines compositing modes for SVG
16:15:16 [heycam]
... some people have asked to have this apply to CSS/HTML
16:15:18 [smfr]
agenda link again please?
16:15:21 [heycam]
... we dont' have a spec for that at the moment
16:15:29 [thorton]
thorton has joined #fx
16:15:31 [heycam]
... in Seattle we decided to investigate it
16:15:43 [heycam]
VH: there is an agreement to have a CSS Compositing spec that would apply to CSS in general
16:15:52 [heycam]
... and the editors are Rik Cabanier and Alex Danilo
16:15:54 [heycam]
... but there is no draft yet
16:16:13 [cabanier]
The phone connection is very bad
16:16:14 [dino]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
16:16:14 [heycam]
CM: applying to both CSS and SVG?
16:17:01 [heycam]
VH: the plan was to take the SVG Compositing spec, fix it up, and make it also apply to CSS
16:17:15 [heycam]
DJ: this is more of a meta question
16:17:19 [ed]
http://www.w3.org/Graphics/fx/track/actions/44
16:17:21 [heycam]
... for SVG Compositing, it seems like the editor was Anthony, who's ...
16:17:25 [heycam]
CC: replaced by me
16:17:30 [heycam]
DJ: do we have implementations of this anywhere?
16:17:38 [heycam]
VH: I think Opera has it
16:17:45 [heycam]
CC: I think the examples in the spec were made with the Abbra player
16:17:54 [vhardy]
s/Opera/Abbra
16:18:01 [dbaron]
dbaron has joined #fx
16:18:14 [heycam]
DJ: there's lots in the spec that is not covered by this, but I'm wondering if it's possible that most of the effects people will want to do is covered by filteres
16:18:17 [heycam]
s/filteres/filters/
16:18:31 [heycam]
... when we've talked to developers who want compositing, they just want e.g. "screen mode" that photoshop can do
16:18:40 [heycam]
... people rarely want to use the porter-duff modes
16:18:44 [heycam]
s/dev/content dev/
16:19:13 [sylvaing]
sylvaing has joined #fx
16:19:15 [heycam]
... so a filter, if there's enough power to do this, typically you have one image and you want to combine it with another one, seems like compositing is a heavyweight solution to a problem that I haven't seen
16:19:21 [heycam]
... not that they don't exist, but not many people are asking to be solved
16:19:32 [heycam]
... in the Compositing spec there's also stuff about clipping to self etc., which makes it more difficult
16:19:40 [Rossen]
Rossen has joined #fx
16:19:57 [heycam]
... then there's the other interesting thing with the spec, browsers now have hardware acceleration, and if you have to read from your background, in many cases it's going to be hard to do that
16:20:16 [heycam]
... for performance, people will need to do compositing in very isolated part of the tree, so that might be better achieved with a filter
16:20:26 [heycam]
VH: even if you do it with filters you'll need background access
16:20:49 [heycam]
... you need something like the BackgroundImage in the filters spec
16:21:19 [heycam]
DJ: which is going to be a difficult thing to support now
16:21:26 [heycam]
... I'm not saying we should drop it, my question is whether people wanting compositing will really want to composite with the page background
16:21:56 [heycam]
VH: I've seen examples where artists turn on blend modes, e.g. add or multiply, and the thing they add to the graph is a blend mode
16:22:01 [heycam]
... it's not like they have a predefined image
16:22:13 [heycam]
... I haven't seen them use porter-duff much, but artists use "add"
16:22:19 [cabanier]
Looking at how people use compositing today in Flash and PDF. it is a very commonly used algorithm.
16:22:27 [heycam]
CM: and you see them blend on to the background?
16:22:28 [heycam]
VH: yes
16:22:30 [cabanier]
I agree that we don't see much point to PD
16:22:34 [heycam]
... they do this in flash too, where it's available
16:23:11 [heycam]
RC: I think it makes more sense in canvas, but a place like SVG or HTML it doesn't really make much sense
16:23:14 [heycam]
... I thought there was a group that really wanted to see PD
16:23:17 [dbaron]
If Porter-Duff were included, could "source" and "dest" be spelled out rather than being src and dst?
16:23:45 [vhardy]
For example: http://fluid.nl/ (look at Space Collective)
16:24:13 [heycam]
DJ: what is the status of the spec?
16:24:30 [heycam]
VH: for SVG Compositing, we had Anthony and Alex being the editors
16:24:33 [heycam]
... not active lately
16:24:51 [heycam]
... we have editors who were willing to take on the work but had limited bandwidth to do so
16:24:58 [stearns]
stearns has left #fx
16:25:12 [heycam]
... so at the moment there's a statement of intent to move the spec to CSS and move it along, but it's limited by people's bandwidth
16:25:13 [heycam]
CC: I can contribute to the editing of this spec, for sure
16:25:20 [heycam]
... I'd like to understand the problem with the background
16:25:23 [heycam]
... is it just enable-background?
16:25:52 [heycam]
DJ: setting it to new is good, but let me talk about how apple/webkit composite
16:26:13 [heycam]
... you could say enable-background:new on an element, the childreno f that element might be composed in separate textures on the gpu
16:26:22 [heycam]
... if you're trying to apply a filter effect on the whole thing, you need to composite it back into one texture, then read it back from the gpu
16:26:32 [heycam]
SF: imagine a div that has webgl under half of it, and something else on the other half
16:26:41 [heycam]
... you have to flatten the webgl and the other thing into a texture, then read it back
16:27:22 [heycam]
... the way our compositing algorithjm works right now is that if something needs to be a gpu texture, it only needs to influence things that are in front in z-order
16:27:34 [heycam]
... so this would add a requirement to look at ththings that are behind it and put those in gpu textures too, and work out when to flatten
16:27:51 [heycam]
CM: so difficult but not impossible?
16:27:57 [heycam]
DJ: it's not that everything is not on the gpu
16:28:15 [heycam]
... imagine you're trying to composite over a page element where something is in webgl and another is filtered
16:28:19 [heycam]
... you've done this on the gpu to composite them together
16:28:44 [shepazu]
shepazu has joined #fx
16:29:02 [heycam]
RC: but that's just a webkit implementation
16:29:14 [heycam]
... you could do it with pixel shaders right?
16:29:14 [heycam]
DJ: it's possible
16:29:24 [heycam]
CC: in acrobat we have hardware acceleration where everything is composited in the gpu, including blend modes and masks
16:29:28 [heycam]
s/CC/RC/
16:30:01 [heycam]
VH: what about using blend modes instead of using shaders? it's more limited in what you can do, but they don't require adding new shaders and reading back stuff
16:30:14 [heycam]
... it's basically an alternate order to your source mode
16:30:26 [heycam]
SF: it's not impossible for us to do this, it's just hard
16:30:30 [stearns]
stearns has joined #fx
16:30:43 [heycam]
EF: on mobile we have severe constraints with the gpu
16:30:52 [heycam]
... so we can't put everything in a texture
16:31:11 [heycam]
... you would normally have one big base layer that is not in a texture
16:31:40 [heycam]
... we've had a lot of people ask us for content developers to find out which things are on the gpu automatically
16:31:50 [heycam]
... people have asked for control in that area, not sure what a good way to do this is, or whether we should
16:32:14 [heycam]
VH: on the blend modes, are you saying that to use non src-over blend modes you need to put the background in a texture?
16:32:18 [heycam]
EF: yes, and we can't do that due to resource constraints
16:32:26 [heycam]
CC: two issues, performance, and the use cases
16:32:44 [heycam]
... performance issue we could put restrictions, this number of textures, that's one thing
16:32:52 [heycam]
... but we should see what are the use cases that could be accommodated with these restrictions
16:33:11 [heycam]
... I hear also that PD might not be the best modes
16:33:11 [heycam]
... we have some use cases for PD
16:33:26 [heycam]
... I'm not fully up to date on them, but I can take an action to provide more use cases on how they can be useful in SVG
16:33:36 [heycam]
... even if the scope is broader, it applies to HTML, keeping the use cases for SVG is important
16:33:54 [heycam]
ACTION: Cyril to provide use cases for blend modes
16:33:54 [trackbot]
Sorry, couldn't find user - Cyril
16:34:34 [paul_irish]
paul_irish has joined #fx
16:34:48 [heycam]
VH: with PD, you never need to read background
16:34:53 [heycam]
... blend modes do need to, though
16:35:26 [heycam]
DB: if the PD modes don't interact with enable-background, what defines what the background is that you're compositing against in those modes
16:35:40 [miketaylr]
miketaylr has joined #fx
16:35:46 [heycam]
VH: In SVG terms it does rely on the notion of what the background is, and there's enable-background property
16:35:51 [miketayl_r]
miketayl_r has joined #fx
16:35:53 [heycam]
CC: if you set enable-background:new, you forget what was on the bg
16:36:13 [heycam]
... and then later int he document that says comp-op:something, you composite that thing with what's on the background between the enable-background:new and now
16:36:19 [heycam]
DB: what if there's opacity?
16:36:29 [heycam]
VH: enable-background:new is like creating a new surface
16:36:37 [heycam]
DB: I know how that works with filter effects
16:36:54 [heycam]
VH: compositing operators are like shorthands for filter affects
16:36:57 [heycam]
s/affects/effects/
16:37:48 [dom]
dom has joined #fx
16:37:49 [heycam]
DB: one other comment from a CSS perspective is that keywords tend not to be abbreviated like "src" and "dst"
16:37:55 [heycam]
... at least they would be "source" and "dest"
16:38:13 [heycam]
DS: I think most people would understand
16:38:15 [heycam]
PL: I think those abbreviations are common in the graphics world
16:38:40 [vhardy]
http://www.w3.org/TR/SVGCompositing/#enable-background-property
16:38:49 [heycam]
SF: canvas has "source-atop"
16:38:55 [heycam]
DB: that feels more CSS-like
16:38:57 [smfr]
canvas: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing
16:39:02 [heycam]
... but maybe I'm just used to it from canvas
16:39:13 [heycam]
DS: isn't this a similar problem to why SVG doesn't have z-index?
16:39:34 [heycam]
SF: doesn't SVG behave like every element is a stacking context?
16:39:36 [heycam]
VH: yes
16:39:44 [heycam]
... the model is any group, you render the group, then composite it with the parent
16:40:13 [heycam]
CC: I think we need to first make sure this is implementable, even on gpus and on mobile with reasonable performance
16:40:25 [heycam]
VH: I would say the implementability is not a question, because we know filters are implemented
16:40:32 [heycam]
... and largely compositing is a shorthand for filters
16:40:48 [heycam]
... it might not be optimal and efficient though
16:40:57 [heycam]
CC: we might need to make changes to the spec to allow efficient implementations
16:40:57 [cabanier]
correct. and we know compositing is working well on mobile devices since Flash is alreayd using it
16:41:06 [cabanier]
on those platforms
16:41:27 [heycam]
SF: I don't know that adding properties is the way to do that, I don't like it when specs have descriptions of resource limitations
16:41:28 [cabanier]
enable-background is the one that might make things slow
16:41:30 [heycam]
... I'd like to avoid that if possible
16:41:59 [cabanier]
but there are tricks to avoid it in most cases
16:42:00 [heycam]
VH: I think the way forward is that we need a converged spec, and we already have an action to produce that
16:42:13 [heycam]
... the thing that has been questioned is PD rules
16:42:14 [heycam]
... coming back to the WG with use cases is good
16:42:35 [heycam]
... then the regular Rec track, see if you get implementations, and if there are problems then it doesn't advance, it's a regular process route
16:42:47 [heycam]
SF: I do agree that we need input from implementors, don't know when we'll get that
16:44:15 [heycam]
CM: are the blend modes useless without being able to read the background?
16:44:15 [heycam]
VH: yes
16:44:28 [heycam]
... you do too for src-over, since there's opacity, but that's already supported
16:44:40 [heycam]
SF: I'm confused by enable-background
16:44:54 [heycam]
... it could use a better name
16:45:15 [heycam]
DB: who implements BackgroundImage?
16:45:15 [cabanier]
Adobe calls it isolate group
16:45:16 [heycam]
ED: Opera, Batik, ASV
16:45:29 [heycam]
DB: I don't how they interact with other features, but that's a separate conversation
16:45:31 [cabanier]
an isolated group = background: false
16:45:42 [heycam]
VH: I think the CSS rendering context is different, how does that work with stacking contexts
16:45:46 [heycam]
... SVG is pure painter's algorithm
16:45:51 [cabanier]
non-isolated = enable-background: true
16:45:57 [heycam]
DB: if this were added to HTML, then enable-background would need to force a stacking context
16:46:16 [ed]
s/ASV/ASV, IE10/
16:46:19 [heycam]
SF: it behaves like non-1 opacity
16:46:19 [heycam]
DB: transforms do the same thing
16:46:45 [heycam]
VH: enable-background is not simple
16:47:15 [heycam]
CC: on the question of implementability, it's difficult but possible?
16:47:16 [heycam]
VH: Adobe has implemented gpu accelerated blend modes
16:47:20 [heycam]
... using pixel shaders
16:47:45 [heycam]
SF: I think HTML/CSS is more complex, we have video and WebGL which makes it harder
16:47:53 [heycam]
DJ: video's a good example of not having access to those pixels
16:48:00 [cabanier]
flash has it in hardware too but they don't have enable-background
16:48:40 [heycam]
SF: to give an indication of how iOS is different, the rendering model is complex and the final rendering is not done in the application
16:48:49 [heycam]
... in your app you won't have access to video frames
16:48:52 [cabanier]
that problem would apply to filters as well. They would need access to the video pixels
16:48:59 [heycam]
... it may not have the ability to do filters etc.
16:49:14 [heycam]
VH: that means the issue you're facing is true for compositing but also for filters
16:49:45 [heycam]
CC: we also need more reports from implementations, nailing down the exact issues that might be impossible
16:50:00 [heycam]
VH: since the issue is really background access, I think this is something we're going to hit pretty soon
16:50:14 [heycam]
... we have one data point from MS
16:50:18 [heycam]
... are the filters in IE10 supported on mobile?
16:50:29 [heycam]
JY: don't know
16:50:39 [heycam]
VH: it would be great data to know, for implementability, on mobile
16:50:58 [heycam]
JY: I could find out
16:51:23 [heycam]
ACTION: Jen to find out whether filters with enable-background are implemented on mobile
16:51:23 [trackbot]
Sorry, couldn't find user - Jen
16:52:19 [dom]
dom has joined #fx
16:52:27 [heycam]
SF: we might figure some of this out while we're doing Filter implementations
16:52:32 [heycam]
VH: we will hit this with shaders as well
16:52:44 [heycam]
ACTION: Vincent to look into implementability of blend modes
16:52:44 [trackbot]
Created ACTION-54 - Look into implementability of blend modes [on Vincent Hardy - due 2011-11-10].
16:52:55 [heycam]
CC: could we remove enable-background?
16:52:56 [heycam]
ED: that's one option
16:53:13 [heycam]
... we could split the parts we don't want out, or have two conformance classes
16:53:13 [heycam]
SF: I hate conformance classes
16:53:17 [heycam]
VH: also blend modes, they need to composite with something
16:53:29 [heycam]
... in the filter you could say you don't have BackgroundImage, but for compositing you need it
16:54:19 [heycam]
... for filters there are certainly things you can do without BackgroundImage
16:54:47 [heycam]
ED: let's wait for feedback then
16:54:54 [heycam]
VH: what does Opera do for mobile?
16:54:58 [heycam]
... for mini, we render on the server
16:55:11 [heycam]
... but it sends a raster back
16:55:12 [heycam]
... for mobile, we do the same implementation as for desktop
16:55:20 [heycam]
... it does render filters, if the hardware is not good, it won't have the best performance
16:55:22 [heycam]
... but it's the same code
16:55:38 [heycam]
s/... for mini/ED: for mini/
16:56:22 [heycam]
CC: should we record the issues in the spec?
16:56:25 [heycam]
VH: yes, wouldn't hurt
16:56:40 [heycam]
ACTION: Cyril to record implementability concerns in the Compositing spec
16:56:40 [trackbot]
Sorry, couldn't find user - Cyril
16:57:47 [heycam]
Topic: clip-path and mask in HTML
16:58:00 [heycam]
ED: I had an action to make clip-path and mask apply to HTML content
16:58:28 [heycam]
... it's already implemented in Firefox
16:58:30 [smfr]
https://developer.mozilla.org/en/CSS/clip-path
16:58:35 [smfr]
https://developer.mozilla.org/en/CSS/mask
16:58:40 [heycam]
... my action was to move the definitions of those properties, and make it work, to the Filters spec
16:58:50 [heycam]
... I don't think it's the right place to put it, but we already have the wording we need for filters
16:59:01 [heycam]
... my question was, wouldn't it be a better match to put it in the compositing spec instead?
16:59:13 [heycam]
CC: it's also an editing question for the SVG spec
16:59:15 [heycam]
ED: it's not somethign that's in the filter chapter currently
16:59:21 [heycam]
s/somethign/something/
16:59:27 [heycam]
VH: would it be more natural to have a CSS Masking & Compsiting spec?
16:59:32 [heycam]
... it would be one more spec
16:59:36 [heycam]
s/Compsiting/Compositing/
16:59:42 [heycam]
... it's a different place in the rendering pipeline
16:59:49 [heycam]
CC: does WebKit support it?
16:59:52 [heycam]
SF: we have two mask properties
17:00:15 [heycam]
... one is equivalent to background-image, the other equivalent to border-image
17:01:01 [cabanier]
Webkit's mask is more of a softmask. It
17:01:04 [cabanier]
is not a clip
17:01:21 [heycam]
AS: it's the luminance from the resulting image that is the mask value
17:01:37 [heycam]
SF: my reaction to these two properties, re clip-path is similar to CSS clip, which already take as rectangle
17:01:43 [heycam]
... it would be nice to do that without SVG
17:01:49 [heycam]
... giving the path in the property
17:01:54 [heycam]
... kind of ugly, but we might want that
17:02:02 [heycam]
... with mask, we found the need to do this 9-piece image thing
17:02:15 [heycam]
VH: is that in a spec?
17:02:15 [heycam]
SF: no
17:02:25 [heycam]
... in CSS it's odd when it interacts with overflow, it always hides overflowing content because the mask never goes past the border box
17:03:24 [smfr]
http://www.webkit.org/blog/181/css-masks/
17:03:50 [heycam]
CC: would IE like it?
17:03:51 [smfr]
https://developer.mozilla.org/en/CSS/-webkit-mask-box-image is the border-image equivalent
17:03:55 [heycam]
JY: seems like something that would be useful in general
17:03:59 [heycam]
... curious if people are asking for it though
17:04:13 [heycam]
SG: in the abstract, it sounds useful, use cases would be helpful
17:04:17 [heycam]
SF: one for masks is that webkit has this box-reflect, and part of that is an image that gets used as a mask
17:04:24 [heycam]
... that's how you get the alpha dropoff in reflections
17:04:31 [cabanier]
Very useful for us. We used it but it was very fragile.
17:04:32 [heycam]
... would be nice to provide enough properties that they could do this themselves
17:04:42 [heycam]
DJ: typically with a gradient
17:05:00 [heycam]
ED: you could do it with filters, the thing that would be hard is transforms
17:05:18 [heycam]
CC: how do we move forward on this?
17:05:33 [heycam]
ED: I have an action to put it into the Filters draft, but I think it's the wrong place
17:05:38 [heycam]
VH: I vote for creating a new draft
17:06:02 [heycam]
SF: I don't care where it goes, but CSS clip should go along side these things
17:06:15 [heycam]
VH: your point is to make these things work together
17:06:27 [heycam]
SF: I would like to see the properties converge
17:06:42 [heycam]
PL: that's why the CSS clip property took a rect() value
17:06:45 [heycam]
... so it could be extended later
17:07:12 [dbaron]
Peter is suggesting clip: path(...) or similar
17:07:23 [heycam]
CM: I don't think people use clip and clip-path
17:07:38 [heycam]
... we could have them be aliases or something
17:07:48 [heycam]
ED: nobody uses clip in SVG content, since it's broken
17:07:52 [heycam]
JY: the definition changed between CSS20 and CSS21
17:08:44 [smfr]
http://www.w3.org/TR/SVG/masking.html#OverflowAndClipProperties
17:09:28 [dbaron]
DB: In CSS 'clip' only applies to absolutely positioned elements
17:09:43 [dbaron]
VH: In SVG it only applies to elements that establish a new viewport (e.g., svg, image)
17:10:11 [vhardy]
http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports
17:10:49 [heycam]
CM: we could have clip-path apply just to SVG content, extend clip to be able to reference paths, have clip apply to both SVG and CSS content, and say clip is the way forward
17:10:58 [heycam]
SF: we would need to extend clip so that it applies not just to SVG viewport creating elemetns
17:11:13 [heycam]
... the other thing, for css, is to define how clip and masking affect hit testing
17:11:28 [heycam]
... I forget if CSS clip makes elements transparent to hit testing?
17:11:38 [heycam]
DB: we don't define that properly, but it should affect hit testing
17:11:41 [heycam]
SF: is the same true of masking?
17:11:52 [heycam]
... we've talked about extending pointer-events to look at alpha
17:12:13 [heycam]
ED: in SVG, clip-path you do get clipping of events
17:12:23 [heycam]
... but for masks it's treated as a raster, and just a rectangle
17:13:42 [ed]
http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
17:13:53 [heycam]
CC: how would you specify the path in CSS? what units would you use for coordinates? the SVG syntax for path doesn't have units.
17:14:13 [heycam]
TA: wonderful question. I would assume that non-united values would work, and map into CSS pxs
17:14:13 [heycam]
... but also allow normal CSS units in there
17:14:19 [heycam]
SF: do you really want to have a path that has mixed units?
17:14:22 [heycam]
TA: maybe it's useful?
17:14:28 [heycam]
DB: there are plenty of existing things that are a bad idea
17:14:30 [heycam]
SG: let's add more!
17:14:36 [heycam]
SF: CSS rect() doesn't have units?
17:14:37 [heycam]
DB: it does
17:14:46 [heycam]
... mixing CSS units between different properties is a bad idea already
17:14:57 [heycam]
... specifying one box's width in ems and aligining it with another that's in px is not going to work
17:15:15 [heycam]
SF: so you're saying it's ok to allow mixed units in paths because it's as bad as things already?
17:15:15 [heycam]
DB: pretty much
17:15:15 [heycam]
TA: you can do that in gradient definitions too
17:15:21 [heycam]
DB: I wouldn't want to forbid other units in a path
17:15:33 [heycam]
SG: there's a difference between mixing them, and using the same unit across the whole path
17:15:42 [heycam]
TA: the problem is that, we could potentially say to use the same units across the path
17:15:49 [heycam]
... that wouldn't be difficult, don't see a lot of use for it though
17:16:11 [heycam]
DB: I also think there are probably useful for different units in paths
17:16:11 [heycam]
... esp with relative units
17:16:15 [heycam]
... one unit in one dimension, and another in the other
17:16:22 [heycam]
VH: or if you want to align things you've done on the page
17:16:32 [heycam]
SG: if you have relative units, and your path changes based on font size, that's weird
17:16:34 [heycam]
... but could be interesting
17:17:15 [heycam]
VH: the pre-1.0 draft of SVG had units in there
17:17:26 [heycam]
... if you specified a stroke-width of 5px, that would be non-scaling
17:17:28 [heycam]
CC: device pixels?
17:17:29 [heycam]
VH: yes
17:17:45 [heycam]
... and that was taken about
17:18:38 [heycam]
... we will have this in transforms, too
17:18:45 [heycam]
... so it might make sense to bring it up as a general issue
17:18:55 [ed]
s/nobody uses clip in SVG content, since it's broken/nobody uses the 'clip' property in SVG content, since it's broken/
17:19:15 [heycam]
created http://www.w3.org/Graphics/SVG/WG/track/issues/2428/
17:19:33 [heycam]
(without the slash on the end)
17:19:37 [heycam]
VH: so we'd need to find editors for this
17:19:58 [heycam]
CC: do we want to resolve on creating a new spec?
17:21:02 [heycam]
RESOLUTION: We will put clip-path and mask in a separate joint FX spec, and merge the clip/mask properties from CSS
17:21:15 [heycam]
DS: so currently you need to reference a clipPath element in SVG
17:21:18 [TabAtkins_]
TabAtkins_ has joined #fx
17:21:19 [heycam]
... have we talked about relaxing that?
17:21:27 [heycam]
SF: I mentioned the desire to have a path directly in the CSS
17:21:38 [heycam]
DS: I meant more referencing an SVG <path>, rather than a <clipPath>
17:21:48 [heycam]
VH: I think we should
17:21:52 [heycam]
... it's the same problem with Exclusiosn
17:21:59 [heycam]
... we want to reference geometry
17:22:12 [heycam]
s/Exclusiosn/Exclusions/
17:22:35 [heycam]
ACTION: Erik to write up a spec for clip/mask in SVG/CSS
17:22:35 [trackbot]
Created ACTION-55 - Write up a spec for clip/mask in SVG/CSS [on Erik Dahlström - due 2011-11-10].
17:24:40 [Rossen]
Rossen has joined #fx
17:25:26 [heycam]
-- 15 minute break, return at 10:40 --
17:29:59 [plinss]
plinss has joined #fx
17:33:26 [heycam]
trackbot, bye
17:33:26 [trackbot]
trackbot has left #fx
17:33:29 [trackbot]
trackbot has joined #fx
17:33:33 [heycam]
trackbot, list users
17:33:33 [trackbot]
Sorry, heycam, I don't understand 'trackbot, list users'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
17:33:50 [heycam]
trackbot, status
17:34:39 [heycam]
dom, are you able to add Jennifer Yu to tracker's list of FX people?
17:38:28 [shepazu]
Zakim, code?
17:38:28 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), shepazu
17:38:43 [heycam]
cabanier, just to reset the timer for people to call in in case they want to, I'm going to hang up
17:38:52 [heycam]
cabanier, then you'll have to call back in (sorry)
17:39:11 [Zakim]
-tpac
17:39:21 [heycam]
Zakim, who is on the call?
17:39:21 [Zakim]
On the phone I see +1.206.675.aaaa
17:39:26 [heycam]
Zakim, hang up +1
17:39:26 [Zakim]
I don't understand 'hang up +1', heycam
17:39:31 [heycam]
Zakim, help?
17:39:31 [Zakim]
Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help.
17:39:34 [Zakim]
Some of the commands I know are:
17:39:35 [Zakim]
xxx is yyy - establish yyy as the name of unknown party xxx
17:39:37 [Zakim]
if yyy is 'me' or 'I', your nick is substituted
17:39:40 [Zakim]
xxx may be yyy - establish yyy as possibly the name of unknown party xxx
17:39:43 [Zakim]
I am xxx - establish your nick as the name of unknown party xxx
17:39:46 [Zakim]
xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group
17:39:48 [Zakim]
xxx also holds yyy - add yyy to the list of participants in group xxx
17:39:51 [Zakim]
who's here? - lists the participants on the phone
17:39:54 [Zakim]
who's muted? - lists the participants who are muted
17:39:57 [Zakim]
mute xxx - mutes party xxx (like pressing 61#)
17:39:58 [heycam]
Zakim, drop +1
17:39:59 [Zakim]
unmute xxx - reverses the effect of "mute" and of 61#
17:40:02 [Zakim]
is xxx here? - reports whether a party named like xxx is present
17:40:04 [Zakim]
list conferences - reports the active conferences
17:40:05 [Zakim]
this is xxx - associates this channel with conference xxx
17:40:08 [Zakim]
excuse us - disconnects from the irc channel
17:40:09 [Zakim]
I last learned something new on $Date: 2010/03/15 18:49:04 $
17:40:11 [Zakim]
- +1.206.675.aaaa
17:40:11 [Zakim]
Team_(fx)15:59Z has ended
17:40:12 [Zakim]
Attendees were tpac, +1.206.675.aaaa
17:40:14 [Zakim]
sorry, heycam, I don't know what conference this is
17:40:20 [pdengler]
pdengler has joined #fx
17:40:24 [heycam]
Zakim, room for 4?
17:40:25 [Zakim]
ok, heycam; conference Team_(fx)17:40Z scheduled with code 26631 (CONF1) for 60 minutes until 1840Z
17:40:31 [Zakim]
Team_(fx)17:40Z has now started
17:40:37 [Zakim]
+ +1.206.675.aaaa
17:40:57 [heycam]
Zakim, code?
17:40:57 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
17:41:07 [Zakim]
+[Microsoft]
17:41:10 [Zakim]
- +1.206.675.aaaa
17:41:11 [Zakim]
+ +1.206.675.aaaa
17:41:18 [Zakim]
+tpac
17:41:29 [stearns]
Zakim, aaaa is cabanier
17:41:30 [Zakim]
+cabanier; got it
17:42:13 [smfr]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
17:43:00 [heycam]
Topic: Transforms
17:43:13 [jun]
jun has joined #fx
17:43:27 [thorton]
thorton has joined #fx
17:43:32 [heycam]
ED: first issue is unification of CSSMatrix/SVGMatrix
17:43:51 [heycam]
DJ: the general topic is that SVGMatrix has been around for a while, but it only supports 2D transforms
17:44:03 [heycam]
... and CSSMatrix we found we needed to add a Matrix API for CSS transforms, which supports 3D
17:44:13 [heycam]
... it's a bit unusual that there's two matrix classes
17:44:17 [heycam]
... recently there was a proposal to add an immutable matrix class
17:44:22 [heycam]
... people are doing lots of math in their JS code
17:44:34 [heycam]
... and copying these matrix objects around is making things slow
17:44:41 [heycam]
CL: so would you be able to instantiate a 3D matrix from a 2D one?
17:44:54 [heycam]
DJ: the main thing we're asking for is being able to do .scale(2) and return a new object
17:45:13 [heycam]
... creating one from the other is not as big a deal
17:45:15 [jen]
jen has joined #fx
17:45:28 [heycam]
... the main issue is that matrix math in JS can be a performance issue, so it would be nice if there were APIs that were native doing this in the browser
17:45:41 [heycam]
... secondly, those APIs should be immutable matrix, so that you don't have to do lots of JSgarbage collection
17:45:56 [heycam]
s/immutable/a mutable/
17:46:02 [efidler]
efidler has joined #fx
17:46:14 [heycam]
DB: one thing that worries me, when you're proposing a mutable matrix, you're adding new methods to the existing type? or a new type?
17:46:25 [heycam]
DJ: we thought about this multiple times, never came up with a good solution
17:46:32 [heycam]
... maybe translateInPlace(), but that looks terrible
17:46:35 [heycam]
... so not sure
17:46:52 [heycam]
SF: the other way to spin this, if we're inventing a new matrix class to be shared across SVG/CSS we want that class to allow mutability
17:46:59 [heycam]
... not extending existing APIs, but adding a new one
17:47:13 [heycam]
DB: one thing abotu mutability and copying, depending on what the APIs are that return them, you might need more copying at the beginning
17:47:18 [heycam]
... since you can't return the same thing twice
17:47:21 [heycam]
... I don't know if that matters
17:47:31 [heycam]
... depends what the APIs that return a matrix are
17:47:37 [heycam]
... with immutable matrices, you can return new ones
17:48:11 [heycam]
CM: you can still write to SVGMatrix's a, b, c, etc.
17:48:12 [heycam]
... even if the methods return new objects
17:48:15 [dbaron]
s/you can/you don't have to/
17:48:20 [heycam]
... so I think implementations don't have that optimization atm
17:48:59 [heycam]
SF: I think the issues are, do we want a new matrix class, where is it specified, does it expose 3d and 3d?
17:49:04 [heycam]
trackbot, status
17:49:30 [heycam]
DJ: mutable and immutable on the same object?
17:49:30 [heycam]
trackbot, status?
17:49:32 [heycam]
CL: that would allow avoiding serialising/reparsing
17:49:50 [heycam]
trackbot, bye
17:49:50 [trackbot]
trackbot has left #fx
17:49:52 [trackbot]
trackbot has joined #fx
17:49:56 [heycam]
trackbot, status?
17:50:01 [heycam]
DJ: we should design it with the idea that it could be used in WebGL?
17:50:22 [heycam]
CL: the declarative 3D people want to come up with new JS types for matrix etc.
17:51:16 [heycam]
CL: is there a concrete proposal?
17:51:23 [heycam]
DJ: there's one in the stage of going from liquid to solid
17:51:30 [heycam]
... there's been a message on the webapps mailing list
17:51:56 [heycam]
SF: a question for implementors who implemented CSSMatrix
17:51:59 [heycam]
ED: opera does
17:52:00 [heycam]
SG: we have
17:52:14 [heycam]
ED: but you can't construct those objects
17:52:15 [heycam]
SF: is the IE implementation exposed to JS?
17:52:16 [heycam]
SG: yes
17:52:19 [heycam]
SF: prefixed?
17:52:19 [heycam]
SF: yes
17:52:25 [heycam]
s/SF/SG/
17:52:36 [heycam]
SF: so this would be an evoluation of the CSSMatrix?
17:52:38 [heycam]
DJ: yes
17:52:52 [heycam]
ACTION: Dean to propose a unified Matrix for SVG/CSS
17:52:53 [trackbot]
Created ACTION-56 - Propose a unified Matrix for SVG/CSS [on Dean Jackson - due 2011-11-10].
17:53:17 [heycam]
ACTION-56?
17:53:17 [trackbot]
ACTION-56 -- Dean Jackson to propose a unified Matrix for SVG/CSS -- due 2011-11-10 -- OPEN
17:53:17 [trackbot]
http://www.w3.org/Graphics/fx/track/actions/56
17:53:54 [heycam]
edited the action
17:54:01 [heycam]
DJ: the other part of the issue is the unification
17:54:15 [heycam]
... now if you want to add 3D transforms to SVG, what do we return?
17:54:45 [heycam]
... given the SVG spec for 10 years has said element.transform you can get an SVGMatrix in there
17:54:52 [heycam]
... with this combined transform spec, we have 3D transforms
17:55:14 [heycam]
CM: so whether we should double up on all these methods on a unified matrix?
17:55:46 [heycam]
VH: so let's have this as an issue to resolve in the spec
17:56:41 [heycam]
DJ: so this is a bit of a hack, because in the 2D spec we define CSSMatrix
17:56:47 [heycam]
... and in the 3D spec we define CSSMatrix
17:56:50 [heycam]
... and they're different
17:56:52 [heycam]
... the 3D only adds
17:57:24 [heycam]
... it would be nice if we could come up with an API that does not break SVG content when an implementation starts supporting 3D
17:57:34 [heycam]
... and without doing something like having rules like "if it's a 2d transform, return an SVGMatrix"
17:57:43 [heycam]
JY: aren't we rehashing the SVG DOM anyway?
17:57:48 [heycam]
DS: yes
17:58:20 [heycam]
CM: we might break some existing stuff
17:58:28 [heycam]
... not sure
17:58:31 [heycam]
ED: I don't think the risk is that high
17:59:15 [Eric]
Eric has joined #fx
17:59:17 [heycam]
CM: there's a,b,c,d,e,f and m00, etc.
17:59:26 [heycam]
DJ: the former are on both SVGMatrix and CSSMatrix, the latter are only on CSSMatrix
17:59:51 [heycam]
CM: I assume then we're not going to get rid of a,b,c etc.
17:59:52 [heycam]
DJ: no
18:00:19 [heycam]
VH: I think this is tractable
18:00:19 [heycam]
... the two fields map to the same values
18:00:34 [heycam]
CM: it's not a huge deal to keep both set of methods either
18:00:55 [heycam]
VH: the Tiny DOM has immutable versions of methods
18:00:57 [heycam]
ED: yes
18:01:02 [heycam]
s/immutable/mutable/
18:01:16 [heycam]
VH: I took an action at the last FX meeting to maek a draft of the merged spec
18:01:25 [heycam]
... under the dev repository there's a transforms spec
18:01:28 [ed]
http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix
18:01:29 [vhardy]
http://dev.w3.org/csswg/css3-transforms/
18:01:53 [heycam]
... so that spec is just 2D transforms, trying to converge with SVG
18:02:00 [heycam]
... I will try to get that spec to be a merged 2D SVG/CSS spec first
18:02:03 [heycam]
... then worry about 3D later
18:02:21 [heycam]
... that's the only update I had
18:02:25 [heycam]
DJ: do we want to publish what we have?
18:02:43 [heycam]
SG: we have these two specs on CSS, and having them at the same time, is a bit weird
18:03:21 [heycam]
SF: I think we also resolved to publish newer WDs of CSS 2D transforms
18:03:31 [heycam]
... but I agree with SG that we should cut over at the same time to the merged spec
18:03:54 [heycam]
ACTION: Vincent to make clear in the merged transforms spec that it hasn't yet replaced the separate specs
18:03:54 [trackbot]
Created ACTION-57 - Make clear in the merged transforms spec that it hasn't yet replaced the separate specs [on Vincent Hardy - due 2011-11-10].
18:06:58 [heycam]
[ discussion of which/whether/when CSS and merged transforms specs get published ]
18:09:55 [plinss]
plinss has joined #fx
18:11:15 [cyril]
cyril has joined #fx
18:15:00 [heycam]
[ concern about 3D holding 2D merged spec back ]
18:15:26 [dbaron]
3D transforms should be in Firefox 10, assuming nothing bad comes up. Firefox 10 expected to ship January 31, per http://en.wikipedia.org/wiki/History_of_Firefox#Expected_Release_Dates
18:16:43 [heycam]
RESOLUTION: We will publish a merged SVG/CSS/2D/3D spec as WD, and republish CSS 2D and 3D with a note about the merged spec
18:17:37 [heycam]
ED: who will do the merging of 3D?
18:17:40 [heycam]
VH: Simon, Dean and myself
18:18:31 [heycam]
s/CSS 2D and 3D/CSS 2D and CSS 3D/
18:19:31 [heycam]
RESOLUTION: We will republish the SVG Transforms module to obsolete it.
18:19:42 [heycam]
ACTION: Cyril to prepare SVG Transforms module for obsolescence.
18:19:43 [trackbot]
Created ACTION-58 - Prepare SVG Transforms module for obsolescence. [on Cyril Concolato - due 2011-11-10].
18:20:19 [heycam]
Topic: CSS Shaders
18:20:28 [heycam]
VH: I can show a demo
18:21:45 [heycam]
[ Vincent shows a demo/presentation of CSS shaders ]
18:23:36 [heycam]
CC: so you having picking there?
18:23:37 [heycam]
VH: no
18:23:43 [heycam]
CL: that's going to be confusing, and limiting
18:23:47 [heycam]
VH: we're working on that issue
18:24:01 [heycam]
... let's get back to that issue later
18:25:28 [dbaron]
dbaron has joined #fx
18:26:00 [heycam]
[ demo continues ]
18:29:02 [heycam]
trackbot, status?
18:29:14 [heycam]
trackbot, bye
18:29:14 [trackbot]
trackbot has left #fx
18:29:16 [trackbot]
trackbot has joined #fx
18:29:23 [heycam]
trackbot, status?
18:38:01 [heycam]
[ issue brought up relating to animation of particular parameters to shaders, and how that is a general problem with css animations, since you have to repeat the whole list of un-animated params too ]
18:38:19 [heycam]
VH: summary of where we stand
18:38:25 [heycam]
... the patch is available
18:38:36 [heycam]
... the main issue we've had is the shader language requirement
18:38:45 [heycam]
... there have been security concerns expressed
18:38:54 [heycam]
... and questions on filter margins
18:38:59 [heycam]
... and pointer events handling
18:39:19 [heycam]
... for the shader language, it's a key decision
18:39:27 [heycam]
... agreeing on one thing will allow content to have just one shader
18:39:38 [heycam]
... otherwise we'll end up in the same situation than audio/video
18:39:44 [heycam]
... which is actually worse, since we're talking about code
18:39:51 [heycam]
... people will need to write shading code twice
18:39:59 [heycam]
... unless there's a way to transcode
18:40:14 [heycam]
... that's a requirement, and orthogonal to the one we picked
18:40:14 [heycam]
... there are only so many solutions here
18:40:26 [heycam]
... we pick an existing shading language or we invent a new one
18:40:43 [heycam]
... maybe a better language comes up in the future
18:40:53 [heycam]
... at adobe we have pixel bender, another shading language
18:40:57 [shepazu]
http://xkcd.com/927/
18:41:13 [heycam]
... which would be suitable for this, but we're not proposing it, because we think it's hard to get adoption for it
18:41:17 [heycam]
... and it'd cause fragmentation
18:41:33 [heycam]
DJ: I also think there's something to be said about choosing a language that's defined as an "open standard", whatever you define that as
18:41:36 [heycam]
... something people can participate in
18:41:44 [heycam]
SF: I think there's also a benefit from choosing a language there's existing content for
18:41:52 [heycam]
DS: something that's used commonly in open source
18:42:12 [heycam]
DJ: the other big thing is WebGL, speaking for GLSL as a shading language
18:42:12 [heycam]
VH: the current draft recommends we converge on GLSL
18:42:28 [heycam]
... the question is to allow other languages, and have a type attribute to select
18:42:41 [pdengler]
Isn't there a method by which we could delivery a model where the language is not defined, much like the codec model for Video?
18:42:52 [heycam]
... like <script> in HTML
18:43:30 [heycam]
VH: HTML5 requires image formats
18:43:30 [heycam]
DS: no
18:43:34 [heycam]
TA: there was no need to
18:43:55 [heycam]
DS: the codec model for HTML is suboptimal
18:44:13 [heycam]
TA: it's horrible, the only reason is because we couldn't agree on codec
18:44:14 [heycam]
SG: what makes you think we can agree on this?
18:44:32 [heycam]
CL: you end up with a bunch of switching, "if i'm on this browser then do this, otherwise do this"
18:44:39 [heycam]
VH: it's a bit different from audio/video, since it's not just transcoding content
18:45:11 [heycam]
CL: can we compile these shaders down to something else?
18:45:12 [heycam]
VH: there are precedents for this
18:45:22 [heycam]
... there was AGAL at adobe
18:45:35 [heycam]
... which allowed GLSL and HLSL to compile down to it
18:45:43 [heycam]
DS: would that inhibit looking at the source?
18:45:47 [heycam]
... because there's power on view-source
18:45:58 [heycam]
VH: so it's view source on the assembly
18:46:13 [heycam]
CL: I'm not asking can we pick another shader language, rather can we compile GLSL down to another language
18:46:38 [heycam]
Johannes Behr from decl 3d
18:46:49 [Rossen]
Rossen has joined #fx
18:46:52 [heycam]
JB: google had a a project ANGLE, which compiles GLSL to HLSL
18:47:11 [heycam]
... people have solved this problem
18:47:17 [heycam]
PD: I want to think about it more
18:47:28 [heycam]
... I will talk to some folks on my side about that
18:47:33 [heycam]
DS: I want to make sure we have that view source
18:47:46 [heycam]
CM: I agree view source is important here
18:47:51 [heycam]
VH: ANGLE is a great point
18:47:58 [heycam]
... chrome has this built in, that's the way they implement WebGL on windows
18:48:13 [heycam]
... that would be an argument for standardising GLSL
18:48:14 [heycam]
... because you could convert in your implementation to HLSL
18:48:36 [heycam]
CM: are there any issues with this?
18:48:49 [cabanier]
the acronym is AGAL
18:48:59 [TabAtkins_]
cyril: The word is "wonks".
18:49:01 [heycam]
cabanier, AGAL is the adobe thing, ANGLE is the chrome thing
18:49:02 [cabanier]
http://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html
18:49:27 [TabAtkins_]
cyril: And it translates roughly to "geeks".
18:49:38 [heycam]
VH: to move forward on this, with the chrome proposal, let's move forward on GLSL. and then ask if we have room for alternative proposals.
18:49:42 [heycam]
... it's similar to scripting, images
18:49:47 [heycam]
... a baseline that everyone has
18:49:54 [heycam]
CL: I'd rather not see that in the first version, it adds uncertainty
18:50:00 [heycam]
... it also means not each language will have the same level of review, etc.
18:50:18 [shans]
http://code.google.com/p/angleproject/
18:50:46 [heycam]
JV: what's nice about glsl is that Khronos is really interested in solving the security issues
18:50:58 [heycam]
DJ: we support mandating GLSL for OpenGL ES 2.0
18:51:12 [heycam]
CL: and the reason for that specific one is that it's more secure
18:51:12 [heycam]
DJ: also it's the version for embedded systems
18:51:15 [heycam]
CL: so performant on mobile
18:51:21 [heycam]
DJ: it's not a functional limitation
18:51:25 [heycam]
... maybe in some extreme shaders
18:51:28 [shepazu]
("wonks" means "people who have very deep, specialized knowledge, and who spend a lot of time tweaking things in a very fine-grained manner")
18:51:36 [heycam]
VH: I'll cover the security concerns
18:51:48 [cyril]
zakim, draft minutes
18:51:48 [Zakim]
I don't understand 'draft minutes', cyril
18:52:13 [cyril]
RRSAgent, draft minutes
18:52:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/03-fx-minutes.html cyril
18:52:13 [heycam]
ED: should we have a vote?
18:52:13 [heycam]
CM: a poll?
18:52:13 [heycam]
VH: three options
18:52:15 [heycam]
... one, GLSL only
18:52:20 [heycam]
... two, GLSL required and allow other languages
18:52:29 [heycam]
... three, don't mandate any particular languages
18:52:58 [heycam]
CL: even if we go for the first option, we should allow specifying another language
18:53:35 [dbaron]
dbaron has joined #fx
18:54:21 [pdengler]
three
18:54:25 [dbaron]
dbaron has joined #fx
18:54:53 [heycam]
CL: this is just a strawpoll
18:54:56 [heycam]
ED: so that's 14 for option one
18:55:12 [heycam]
... 1 for option two
18:55:29 [heycam]
... 1 for option three
18:55:43 [heycam]
DS: option two does give us the future proofing thing
18:55:49 [heycam]
CL: the way I was arguing it was that option one also does
18:56:13 [heycam]
... in PNG there's a byte that allows specifying which compression method is used
18:56:13 [heycam]
... but there's only one value allowed
18:56:19 [heycam]
... but it's there to possibly extend in the future
18:56:52 [heycam]
VH: on the security concerns
18:56:56 [heycam]
... I wanted to recap what's been raised
18:57:14 [heycam]
... in general, with WebGL and shaders, there have been 3 concerns
18:57:14 [heycam]
... one, DoS
18:57:14 [heycam]
... hogging the GPU
18:57:25 [heycam]
... two, timing attacks
18:57:29 [heycam]
... three, memory overflows
18:57:41 [heycam]
... which doesn't actually pertain to css shaders, more about WebGL APIs, which has been taken care of in the spec
18:57:51 [heycam]
... those three things are being dealt with for WebGL
18:58:00 [heycam]
... a company did a PoC for timing attacks
18:58:14 [heycam]
... the WebGL group has been tightening up the spec to respond to these
18:58:32 [heycam]
... all these issues are being resolved for WebGL
18:58:40 [heycam]
... DoS is being dealt with at the driver or OS level
18:58:47 [heycam]
s/all these/the memory overflow/
18:59:11 [heycam]
... the system has a way to detect if the gpu is hogged, so that the application can be informed and be able to kill the context
18:59:16 [heycam]
... there's work being done with gpu vendors to build this in to hardware
18:59:26 [heycam]
... timing attacks, webgl is addressing this with cors
18:59:36 [heycam]
... so you won't be able to process images from other domains unless you use CORS to allow this
18:59:41 [heycam]
... let me talk a bit about timing attack
18:59:43 [heycam]
s/attack/attacks/
18:59:57 [heycam]
... basically, the crux of a timing attack is that there's come content I can't get my hand on
18:59:59 [heycam]
... and rendering it on the page
19:00:12 [heycam]
... browsers have prevented me from getting to pixel values in the content
19:00:19 [heycam]
... but one thing I can do is measure how long the content takes to get rendered
19:00:28 [cyril]
see http://www.contextis.co.uk/resources/blog/webgl/
19:00:30 [heycam]
... very simple example, if I have an image that has no colour
19:00:34 [heycam]
... just translucent pixels
19:00:39 [heycam]
... and I know my browser renders that really fast
19:00:50 [heycam]
... but another image with all opaque pixels is slower
19:01:12 [heycam]
... and let's say your bank has an image that is either translucent or green, representing whether hte password typed in is correct
19:01:30 [heycam]
... I can time how long it takes to render that piece of content, infer whether the image was translucent or green, and thereby determine the password
19:01:38 [heycam]
... shaders help that kind of attack, since they can influence the time of rendering
19:01:50 [heycam]
... based on the pixel values, you can make it longer for some values and shorter for other values
19:01:57 [heycam]
... you can do that individually for each pixel values
19:02:12 [heycam]
... so you can determine the pixel values without being able to get to them directly in the dom
19:02:29 [heycam]
... in WebGL the PoC showed that you get fuzzy results, and it takes time, but the underlying threat is there
19:02:40 [heycam]
... one thing to understand is that shaders will make this worse, but the problem exists regardless of shaders
19:02:56 [heycam]
... with a general iframe, you could start inferring what's in the iframe just based on rendering time
19:03:14 [heycam]
... maybe that's low bandwidth enough not to get information out quickly enough
19:03:15 [heycam]
... possible solutions, one is to say use CORS
19:03:27 [heycam]
... so anything you render, if it's cross domain, you'll get a blank image
19:03:45 [heycam]
... I think this is what the WebGL group is doing to address this attack
19:04:19 [heycam]
... in WebGL you can do the attack by getting the time just before the shader runs and just after the shader runs, so that's a pretty precise time measurement
19:04:19 [heycam]
s/WebGL/shader/
19:04:28 [heycam]
... but for general content you'd need to use requestAnimationFrame or something similar, and that's less precise
19:04:47 [heycam]
... so implementations needs to be careful in general with setTimeout and requestAnimationFrame
19:04:50 [heycam]
... information can be leaked there
19:05:12 [heycam]
... I talked to our security experts on the Flash platform, the parallel they drew was something happening on the network
19:05:20 [heycam]
... if you're on a webpage, broadcasting network addresses to everything on the network
19:05:30 [heycam]
... if you get immediate failure, you know that IP address is on the network
19:05:40 [heycam]
... the way to address this is inserting timeouts that happen no matter what
19:05:45 [heycam]
... the failure would come sooner or later
19:05:50 [heycam]
... so they were similarly using time
19:05:56 [heycam]
... their solution was to hide the time by adding extra noise to it
19:06:01 [heycam]
... might be other options, haven't heard them so far
19:06:16 [heycam]
TA: in general the last requirement is impossible, since browser have to be cryptographically secure
19:06:24 [heycam]
... basically impossible for rendering I assume
19:06:29 [heycam]
... but we do need to handle timing attacks somehow
19:06:35 [heycam]
VH: my suggestion would be to go for the CORS solution
19:06:40 [heycam]
... and sync up with the webapps group
19:06:47 [heycam]
TA: I'm confused how CORS helps here
19:06:58 [heycam]
... in other cases, with canvas, you're explicitly saying to render this image/video to the canvas
19:07:13 [heycam]
... with shaders, you need to say "hey webpage, is anything in the page cross origin"?
19:07:14 [heycam]
VH: it's the same problem with SVG painting to canvas
19:07:19 [heycam]
... atm we taint unconditionally
19:07:28 [heycam]
... but we'd like to know if any cross origin resources are used
19:07:38 [heycam]
SF: if we add compositing, that also lets you get information below the element
19:07:42 [heycam]
... so you need to worry about the whole document
19:07:51 [heycam]
TA: we already have simple things, like being able to detect :visited state
19:07:56 [heycam]
... a timing channel attack is very viable on that
19:07:59 [heycam]
... in less than a second
19:08:19 [heycam]
VH: getting computed style?
19:08:19 [heycam]
TA: no, using timing channel attacks
19:08:20 [heycam]
... you can extra 5-10 bits of data per second on that
19:08:22 [heycam]
... if you're just using the rendered layer
19:08:27 [heycam]
... we already hide information from the DOM
19:08:37 [heycam]
... so we already need to be handing a modified layer to the shader beforehand
19:08:44 [heycam]
... at that point, blanking out iframes might not be as big of a deal
19:08:53 [heycam]
... since we already have to be handing things different from what's being rendered on the screen
19:09:13 [heycam]
VH: in the shader you can get that information, but then how do you get that information back to the site?
19:09:34 [heycam]
TA: that's the timing channel
19:09:59 [heycam]
... the :visited thing itself will require changes to the layer we hand to css shaders
19:10:13 [heycam]
SF: we've been disussing similar issues with the desire to draw arbitrary elements into the canvas
19:10:15 [heycam]
VH: I think it's the same issue
19:10:23 [heycam]
SF: hiding iframes, links, is like playing whackamole
19:10:31 [heycam]
... there are unknown pieces of privacy data we need to hit on the head
19:10:40 [heycam]
... adam is worried about this whackamole approach
19:10:44 [heycam]
VH: where can we discuss these issues?
19:11:19 [heycam]
... webapps?
19:11:24 [heycam]
SF: we should get adam barth in here
19:11:40 [heycam]
VH: there's no resolution we can take right now on security
19:12:11 [heycam]
DJ: the things we can decide/discuss now is, whether to combine css shaders into the filters spec
19:12:12 [heycam]
... tab disagreed
19:12:13 [heycam]
... for two reasons, and this was one of the reasons
19:12:33 [heycam]
... the question is, now that we've talked it through, css shaders makes this problem worse, is it enough to say it shouldn't be included in the spec?
19:12:42 [heycam]
TA: I don't think there's a necessity to have them in the same spec
19:13:12 [heycam]
... the fact that i'm pretty sure this will slow down shaders
19:13:12 [heycam]
CM: slow down filters you mean?
19:13:24 [heycam]
TA: I believe that filters has feCmponentTransform
19:13:32 [heycam]
... I think the rate at which you could extract data is lower than this
19:13:44 [heycam]
... if you're getting only a bit a second, that drops it into the probably not a concern bucket
19:13:49 [heycam]
SF: because filters will be implemented in software?
19:13:58 [heycam]
TA: no, but you can't do such dramatic changes to timing
19:14:15 [heycam]
VH: let's get adam barth here
19:15:16 [heycam]
DJ: adam is not here today
19:15:24 [heycam]
VH: let's get him on a call
19:15:30 [heycam]
VH: the next issue is filter margins
19:15:41 [heycam]
... this has been discussed on filter effects in general
19:15:52 [heycam]
... there's no margins in svg
19:15:55 [heycam]
... there's filter regions
19:16:12 [heycam]
... people either get it wrong, and are unhappy with what they get, or they don't bother and set it to the entire viewport
19:16:21 [heycam]
... and then implementations need to second guess the region
19:16:26 [heycam]
ED: yes, if you don't optimize it
19:16:39 [heycam]
VH: with a lot of filters you can compute the filter region automatically
19:17:21 [tav]
tav has joined #fx
19:18:13 [heycam]
... we found with shaders that it's not possible to compute the filter region properly for trivial shaders
19:18:14 [heycam]
... with vertex shaders, it's hard to know what the user wants
19:18:34 [heycam]
... when you try to compute ti, then animate it, you can optimize that kind of problem but then your filter region changes over time
19:18:36 [ChrisL]
ChrisL has joined #fx
19:18:45 [heycam]
... we found it more efficient that you specify the array you need
19:19:02 [ChrisL]
rrsagent, here
19:19:02 [RRSAgent]
See http://www.w3.org/2011/11/03-fx-irc#T19-19-02
19:19:02 [heycam]
CM: why won't this have the same problems as with SVG specified regions?
19:19:13 [ChrisL]
zakim, this meeting spans midnight
19:19:13 [Zakim]
I don't understand 'this meeting spans midnight', ChrisL
19:19:32 [ChrisL]
rrsagent, this meeting spans midnight
19:19:36 [heycam]
VH: I feel margins is already a better way to talk about it in CSS, since margins are additional offsets on the box
19:19:44 [heycam]
... for documentation on shaders, I'd expect it to say how to compute the margins
19:19:57 [heycam]
... also I don't have any good suggestions about how to compute margins automatically
19:20:21 [heycam]
... we discussed this on the list, an exchange with Dirk, I explained how SVG filter margins work, but he hasn't responded
19:20:31 [heycam]
CL: I had initially agreed with Dirk but now I agree with you
19:20:43 [heycam]
SF: your proposal is that the author specifies the filter margin
19:20:45 [heycam]
VH: yes
19:20:56 [heycam]
... there's a note in the spec to say that if the way you can compute the filter margin...
19:21:01 [heycam]
SF: but you can't do that without running the shader
19:21:14 [heycam]
VH: and you need to know the size of the surface
19:21:19 [heycam]
... so right now we have margins, but if we find a better way we will specify that
19:21:48 [heycam]
... so the shader margins default to -10%,-10%,120%,120%, i.e. the same as svg filter regions
19:21:56 [heycam]
... one final issue is pointer events and picking
19:21:59 [heycam]
... don't have a lot to say there
19:22:14 [heycam]
... I think we all agree that it's desirable you can do proper selection and interactivity on shaded content
19:22:20 [heycam]
... some ideas have been bounced around, it's non trivial
19:22:37 [heycam]
CL: you get projections which are noninvertable
19:22:40 [heycam]
VH: yes, that
19:22:48 [heycam]
... you need an inverse from what the shader does
19:23:13 [heycam]
... in the rendering pipeline you can't get the output of the vertex shader
19:23:47 [heycam]
CM: could you allow the author to specify a mapping back to user coordinate space?
19:24:13 [heycam]
TB: yes, we allow the author to specify a shader to reverse the transformation
19:24:24 [heycam]
... if you are interested in precise picking positions
19:24:42 [heycam]
VH: it does the inverse transform?
19:24:51 [heycam]
TB: no, the buffer will contain final coordinates encoded as colours
19:24:56 [heycam]
... and then you read back the buffer
19:24:57 [Zakim]
-[Microsoft]
19:24:59 [heycam]
... not as part of the webpage
19:25:18 [heycam]
DJ: it's not the inverse transform?
19:25:19 [heycam]
TB: no
19:25:25 [heycam]
DJ: we want to know where the input was
19:25:25 [dbaron]
dbaron has joined #fx
19:25:42 [heycam]
TB: you just look up the position
19:25:46 [heycam]
DJ: ok so it is the transform then
19:26:20 [heycam]
EF: you would frequently have to do this
19:26:30 [heycam]
TB: with modern gpus, the second option is to do it on the cpu
19:26:49 [heycam]
VH: the picking buffer, I didn't completely get it, are there docs?
19:26:53 [heycam]
TB: use
19:26:57 [heycam]
s/use/yes/
19:27:12 [heycam]
SF: why not just let JS do it?
19:27:29 [heycam]
s/TB/DB/
19:27:32 [heycam]
s/TB/DB/
19:27:35 [heycam]
s/TB/DB/
19:27:48 [heycam]
[ various TBs in this recent issue discussion should be DBs ]
19:28:23 [heycam]
VH: so one thing I can do short term is to add those options/ideas to the draft
19:28:42 [heycam]
... I think that's all we had
19:28:55 [heycam]
... there was a proposal on the list, Charles brought up the idea of a JS based shading language
19:29:01 [ed]
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0052.html
19:29:01 [heycam]
... I think Dean responded saying that it's too early to do this
19:29:13 [heycam]
... I've talked to people internally, who think it's a bad idea
19:29:18 [heycam]
... they told me there were reasons to use a C-like language
19:29:27 [heycam]
... typing is important in the shader
19:29:46 [heycam]
... we've moved all the issues to the bugzilla
19:30:00 [heycam]
... I just want to know what the next step for the document is
19:30:02 [Zakim]
-cabanier
19:30:19 [heycam]
... it's an editor's draft now
19:30:19 [heycam]
... if we keep it as a separate editor's draft, we need a space to put it
19:30:21 [heycam]
... since it's not an "official" editor's draft
19:30:30 [heycam]
... my preference is to merge it into the next Filters WD
19:31:13 [heycam]
CM: I would rather have them separate
19:31:20 [heycam]
... shaders could slow down the progress of Filters
19:31:31 [heycam]
VH: the shader implementation is actually simpler than Filters
19:31:50 [heycam]
TA: but we already have filter implementations
19:31:58 [heycam]
CL: we have many existing mature filters implementations
19:32:15 [heycam]
... however, even if we decide not to merge them, I would like to have a FPWD of it
19:32:28 [heycam]
VH: yes, I'd be happy with either agreeing to merge it and include it in the next WD
19:32:40 [heycam]
... or to publish it as a separate FPWD
19:32:47 [heycam]
TA: there's no downside to having it as a separate draft
19:32:55 [heycam]
DJ: I don't have any technical reason
19:33:01 [heycam]
... the reason I like it is that Filters already had a feCustom
19:33:12 [heycam]
... it has a suggestion of this element
19:33:12 [heycam]
... this is fleshing out that bit
19:33:13 [heycam]
... it really is part of filters
19:33:29 [heycam]
... it sends a clear message that you can use this technology to do this kind of effect
19:34:01 [heycam]
TA: I understand the aesthetic concerns, but it's not a bad thing to split out and have small specs
19:34:13 [heycam]
... especially when they have different maturity levels
19:34:19 [heycam]
... we've solved filters with svg
19:34:22 [heycam]
... there are minor issues
19:34:31 [heycam]
... but it's mostly a solved spec
19:35:03 [Zakim]
disconnecting the lone participant, tpac, in Team_(fx)17:40Z
19:35:05 [Zakim]
Team_(fx)17:40Z has ended
19:35:06 [Zakim]
Attendees were +1.206.675.aaaa, [Microsoft], tpac, cabanier
19:35:29 [heycam]
[ Any "DB" in the shaders discussion is really "JB". ]
19:36:51 [heycam]
DS: are there issues that are common to both, and which will be solved when we think about them for shaders?
19:36:53 [heycam]
DJ: pointer events
19:37:11 [ChrisL]
[and JB is Johannes Behr , chair of the Declarative 3D for the Web Architecture Community Group]
19:37:24 [ChrisL]
[ http://www.w3.org/community/declarative3d/ ]
19:37:26 [heycam]
VH: I think Dean and I's preference is to keep a single spec
19:37:56 [heycam]
CM: I don't object to having them in a single spec
19:38:36 [heycam]
TB: it's my preference to being split out, I won't object to them being in the same spec
19:38:44 [heycam]
DJ: we haven't even published the first draft of the filters spec
19:38:46 [shans_]
shans_ has joined #fx
19:39:18 [heycam]
RESOLUTION: We will add CSS Shaders into the Filter Effects spec.
19:39:37 [heycam]
ED: do we still want to publish the Filter Effects draft without it first?
19:39:43 [heycam]
VH: I say both at the same time
19:40:19 [heycam]
RESOLUTION: We will publish the Filter Effects draft once CSS Shaders has been added.
19:40:30 [heycam]
ACTION: Vincent to add CSS Shaders to the Filter Effects spec and ready it for publishing.
19:40:30 [trackbot]
Created ACTION-59 - Add CSS Shaders to the Filter Effects spec and ready it for publishing. [on Vincent Hardy - due 2011-11-10].
19:41:10 [heycam]
VH: So we will keep the issue of shader language flagged in the spec first, but not resolved yet.
19:42:13 [heycam]
ACTION: Vincent to get security experts to talk with the FX group about CSS Shaders security issues
19:42:13 [trackbot]
Created ACTION-60 - Get security experts to talk with the FX group about CSS Shaders security issues [on Vincent Hardy - due 2011-11-10].
19:42:44 [heycam]
-- Lunch, we will resume at 2pm --
20:00:48 [Tavmjong]
Tavmjong has joined #fx
20:02:24 [dom]
dom has left #fx
20:19:23 [stearns]
stearns has joined #fx
20:28:17 [sylvaing]
sylvaing has joined #fx
20:32:31 [dbaron]
dbaron has joined #fx
20:42:58 [jun]
jun has joined #fx
20:43:53 [sylvaing]
sylvaing has joined #fx
20:49:10 [plinss]
plinss has joined #fx
20:52:13 [shepazu]
shepazu has joined #fx
20:56:48 [smfr]
smfr has joined #fx
20:57:13 [heycam]
Zakim, code?
20:57:13 [Zakim]
the conference code is hidden, heycam
20:57:20 [heycam]
Zakim, room for 4?
20:57:22 [Zakim]
ok, heycam; conference Team_(fx)20:57Z scheduled with code 26631 (CONF1) for 60 minutes until 2157Z
20:57:43 [jen]
jen has joined #fx
20:57:54 [jen]
jen has joined #fx
20:57:59 [Zakim]
Team_(fx)20:57Z has now started
20:58:04 [Zakim]
+tpac
20:59:57 [Zakim]
+cabanier
21:00:33 [Rossen]
Rossen has joined #fx
21:01:25 [heycam]
Topic: Mesh gradients
21:01:53 [Zakim]
+tbah
21:02:52 [heycam]
ED: we're doing mesh gradients as one of the new features for SVG2
21:03:10 [stakagi]
stakagi has joined #fx
21:03:12 [heycam]
... I think the point of bringing this up in the FX meeting was to see if there was interest with using that, or having that in a CSS syntax
21:03:20 [heycam]
... I wanted to give Tav the opportunity to present what he's done in Inkscape
21:03:31 [cyril]
cyril has joined #fx
21:04:53 [Tavmjong]
http://tavmjong.free.fr/SVG/SVGOpen2011/MESH/svg_2011_mesh.svg
21:05:27 [ChrisL]
ChrisL has joined #fx
21:05:38 [heycam]
[ Tav presents his gradient mesh work ]
21:05:50 [ChrisL]
rrsagent, here
21:05:50 [RRSAgent]
See http://www.w3.org/2011/11/03-fx-irc#T21-05-50
21:06:17 [stearns]
stearns has joined #fx
21:06:54 [efidler]
efidler has joined #fx
21:09:23 [heycam]
[ Proposed SVG syntax: http://tavmjong.free.fr/SVG/SVGOpen2011/MESH/svg_2011_mesh.svg#14_0 ]
21:09:29 [dino]
dino has joined #fx
21:13:52 [heycam]
SF: question on implementation
21:13:57 [heycam]
... how expensive is it to render these?
21:14:13 [heycam]
... existing gradients are fairly expensive to repaint already
21:14:15 [heycam]
... seems like this would be more expensive to paint
21:14:20 [heycam]
CL: these are implemented in Inkscape
21:14:27 [heycam]
... an editor has to deal with redraw issues
21:14:37 [heycam]
... do you have noticeable redraw lags?
21:15:00 [heycam]
TB: not really, if you zoom way in and move them quickly there is some lag
21:15:20 [heycam]
CM: this is already required for PDFs
21:15:27 [heycam]
SF: but PDFs aren't performance critical
21:15:28 [cabanier]
if you go the GPU route, they are easy to draw.
21:15:51 [heycam]
SF: CoreGraphics does not support this
21:15:57 [heycam]
... so we'd need to impleement this ourselves
21:15:57 [cabanier]
you could possibly do it with CSS shaders...
21:16:13 [heycam]
... I'm not against them, just saying there may be performance considerations
21:16:17 [heycam]
JY: how useful would it be for CSS?
21:16:23 [heycam]
in SVG you have non-square shapes everywhere
21:16:28 [heycam]
... seems like it would be less valuable for HTML
21:17:12 [ChrisL]
if it was found useful to use these in CSS I would suggest a url() reference to some svg, rather thant eh @-rule-from-hell approach
21:17:26 [heycam]
Topic: Filter effects
21:17:34 [heycam]
ED: to go through a few of the issues that came up on the mailing list
21:17:45 [ed]
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0031.html
21:18:17 [heycam]
... the list of shorthand filters, we keep that in?
21:18:17 [heycam]
... this isn't adding anything, but just raising some issues
21:18:17 [heycam]
DJ: there were two issues
21:18:29 [heycam]
... one is that an apple engineer pointed out greyscale is the same as saturation
21:18:39 [heycam]
... with the exception that saturation could go beyond 100%
21:18:49 [heycam]
... the good thing about greyscale is anyone can understand what it does
21:19:11 [heycam]
... are we ok keeping something that is effectively a duplicate?
21:19:11 [heycam]
DS: I think it's fine
21:19:12 [heycam]
... people will look for it
21:19:14 [heycam]
ED: I think so too
21:19:30 [heycam]
CM: I think greyscale is going to be the kind of saturation most people want to use anyway
21:19:44 [heycam]
DJ: next, sharpen
21:19:58 [heycam]
... we had feedback suggesting that in most cases, thinking about what's the use case for a sharpening filter
21:20:12 [heycam]
... it'll be people with digital photography wanting to make it look better
21:20:15 [heycam]
... it's not likely people will want to put unprocessed photographics on a webpage
21:20:23 [heycam]
... the sharpen effect in the filter spec isn't what anyone wants to use
21:20:34 [heycam]
... all these tools have a custom sharpening filter that is a lot more complicated than what's there
21:20:39 [heycam]
... so the suggestion is just to remove it
21:20:51 [heycam]
CL: that's a bit sad, there are many people who would be happy with sharpen as it is
21:21:23 [heycam]
... using an image at different sizes, and being able to sharpen it
21:21:29 [heycam]
... for the smaller one you want to sharpen it a bit
21:21:36 [heycam]
DJ: the feedback was you could still use CSS Shaders to do this
21:22:13 [heycam]
... the question is, even the phones nowadays have some image processing on them
21:22:19 [heycam]
... uploading the raw image is becoming less common
21:22:49 [heycam]
DS: rather than argue about this now, that we simply put this in the court of public opinion?
21:22:56 [heycam]
... I would say, drop it for now, and if we want it later add it
21:23:13 [heycam]
... identify use cases for what this thing can do
21:23:18 [heycam]
SF: a good way to approach this is that css filters should allow you to do two types of things
21:23:25 [shans]
shans has joined #fx
21:23:26 [heycam]
... one is to animate something, do some kind of transition to make things pretty
21:23:36 [heycam]
... second, they should allow you to reduce the number of image assets you have
21:23:47 [heycam]
... something like sharpen, which you want to do permanently once, should have already been done
21:23:50 [heycam]
... before uploading
21:24:00 [heycam]
... that'd be my reasoning to be able to to this
21:24:17 [heycam]
DS: there are some tools that allow this
21:24:25 [heycam]
SF: but not to save the output of the filtered output
21:24:32 [heycam]
... maybe canvas.drawElement will allow us to do that
21:24:46 [heycam]
DS: mark it at risk?
21:24:46 [heycam]
DJ: ok
21:25:49 [heycam]
RESOLUTION: We will mark sharpen shorthand and feSharpen as at risk.
21:25:58 [heycam]
RESOLUTION: We will keep greyscale shorthand.
21:26:13 [heycam]
DJ: many of these shorthands take the first parameter as amount
21:26:14 [heycam]
... 0 = no effect, 1 = full effect
21:26:24 [heycam]
... would it be better to accept percentage values as well?
21:26:36 [heycam]
... 100% greyscale makes more sense to some people than 1
21:26:44 [heycam]
SF: accepting both fractions and percentages?
21:26:51 [heycam]
... we talked about this in the context of crossfade
21:26:54 [heycam]
TA: I'm in favour of this
21:27:19 [heycam]
VH: unitless is a normalised value?
21:27:19 [heycam]
DJ: we should clamp
21:27:22 [heycam]
... this spec needs to change to be more like what image values says, which defines a grammar for each thing, instead of text prose
21:27:31 [heycam]
... the question about parsing is something we've come up against in implementation
21:27:33 [cyril]
the term shorthand is not used consistently in the spec
21:27:43 [heycam]
... when taking multiple parameters, should it be invalid if we put commas?
21:27:44 [TabAtkins_]
TabAtkins_ has joined #fx
21:27:55 [cyril]
sometimes it's filter function sometimes shorthand
21:28:11 [heycam]
... I like the idea of CSS being very permissive, otoh I don't like it if they've accidentally made an error then it's hard to understand the result
21:28:19 [heycam]
... might be a good thing, stylistically, to know what happened when something when wrong
21:28:25 [heycam]
TA: fail quickly and as tinily as possible
21:28:34 [heycam]
DJ: at the moment we fail for things with commas in them
21:28:40 [heycam]
... so if you put gamma(1,1,1) the whole property would fail
21:28:46 [heycam]
... CSS Shaders has a comma separated parameter list
21:28:50 [heycam]
... so that's a bit different
21:28:58 [heycam]
TA: that one has constraints on it, the syntax is sufficiently complex to warrant commas
21:29:55 [heycam]
RESOLUTION: We will accept percentages for 0..1 values in shorthands.
21:30:13 [heycam]
RESOLUTION: We will have the shorthand properties fail to parse if using commas where not allowed, etc.
21:30:17 [heycam]
DJ: I'll update the spec to be less prose, have a defined grammar.
21:30:23 [heycam]
CC: can you also add a definition of shorthand?
21:30:30 [heycam]
... sometimes it's called filter function, sometimes called shorthand
21:30:48 [ChrisL]
zakim, settle down :)
21:30:48 [Zakim]
I'm glad that smiley is there, ChrisL
21:31:13 [heycam]
CM: shorthand means something else in CSS
21:31:32 [heycam]
DJ: that's all on the filter functions
21:32:13 [heycam]
ED: a couple of people have been requesting ...
21:32:20 [heycam]
DJ: currently you can't transform the filter in any way, do a blur then scale it by 1.5 for example
21:32:33 [heycam]
... the proposal is to add a filter function and element, feTransform
21:32:46 [heycam]
DS: Anthony Grasso proposed something similar a couple of years ago at SVG Open
21:32:51 [heycam]
... one would be to do the filter reflection effect
21:32:59 [cyril]
http://lists.w3.org/Archives/Public/public-fx/2011JulSep/0082.html
21:33:12 [heycam]
... I was wondering if it made sense instead of feTransform, but to put a transform on a particular filter
21:33:16 [heycam]
CL: it doesn't fit into the node filter model as nicely
21:33:36 [heycam]
... if we were to add feTransform, you'd need to decide what happens when you get pixels that aren't covered
21:33:43 [heycam]
DJ: in CSS Shaders there's a similar issue
21:33:52 [heycam]
... you need to define what happens outside the mesh
21:34:13 [heycam]
CL: is the shader writer required to cope with that?
21:34:13 [heycam]
DJ: no
21:34:15 [heycam]
... in GL you define this as part of the state you set u
21:34:18 [heycam]
s/set u/set up/
21:34:28 [heycam]
... the texture either repeats, clamps
21:34:39 [heycam]
... the feTransform is an operation on its input and it produces a new output
21:34:43 [Zakim]
-cabanier
21:34:48 [heycam]
... that allows it to sit in the filter function list
21:35:02 [heycam]
CC: what kind of transform?
21:35:11 [heycam]
DJ: only 2D affine transforms
21:35:21 [heycam]
CC: coudl it be an extension to the feDisplacementMap
21:35:25 [heycam]
s/coudl/could/
21:35:43 [heycam]
CL: it's simpler to say scale(2,0.5) than to work out what the RGB image should be for feDisplacementMap
21:35:52 [heycam]
... feDisplacementMap is still useful for non-affine
21:36:12 [heycam]
EF: you get people trying to do perspective transforms
21:36:13 [heycam]
CL: why restrict it to affine?
21:36:18 [heycam]
... especially if we're adding non-affine in SVG2?
21:36:28 [heycam]
... if people can do it in one place they'll expect to do it in another
21:36:50 [heycam]
DJ: can't think of a good reason why not
21:37:12 [heycam]
CL: picking the SVG 1 transform set is a good start, but if SVG2 is extending that to include non-affine...
21:37:12 [heycam]
... if you have it there, you'd want it in the filter as well
21:37:18 [heycam]
DJ: it should just take a transform
21:37:31 [heycam]
CL: it'll just point to the Transforms chapter, ok
21:37:38 [heycam]
CL: do we need to say anything about resampling?
21:37:46 [heycam]
DJ: we should say something in the filters spec in general
21:37:56 [heycam]
CL: we have some talk about resampling for raster images in the spec
21:38:13 [heycam]
DJ: when we merge shaders and filters it should be a separate section that covers both
21:38:13 [heycam]
VH: there is an open issue on that
21:38:29 [heycam]
... we need a way to specify the interpolation method when scaling up and scaling down
21:39:18 [heycam]
DJ: this addresses Dirk's request from January
21:39:18 [heycam]
... doesn't address perspective transforms
21:39:51 [heycam]
... the other part of the proposal in my email was that when you do a filter effect, you don't necessarily want to replace the element you're drawing
21:39:56 [heycam]
... but to blend with it
21:40:02 [heycam]
... with the canned filter effects it's not as easy to blend
21:40:20 [heycam]
... so maybe we should have a keyword that allows you to composite the element with its filtered result
21:40:36 [heycam]
... the question is, whether doing something like that a common enough use case that we want it to canned effects
21:40:42 [heycam]
... or complicated enough to leave it to the markup version of filters
21:40:47 [heycam]
TA: I think it's an easy and ocmmon use case
21:41:22 [heycam]
DJ: I was proposing two keywords, composite-over and composite-under
21:41:40 [heycam]
... you would use that anywhere in the list
21:41:43 [heycam]
... (which would be a bit strange)
21:41:48 [heycam]
... not sure it's a good idea, but I made the proposal
21:43:02 [heycam]
... composite-under right at the end would be like doing an feMerge with all the others, and merging it with SourceGraphic
21:43:14 [heycam]
... or drawing it twice one without the filter one with
21:43:25 [heycam]
CL: I think that's useful functionality
21:43:30 [heycam]
... clear to explain with a couple of examples
21:43:35 [heycam]
... simple enough to have it canned
21:43:55 [heycam]
DJ: I still want to go back and see why Simon doesn't think it's a good idea
21:44:03 [vhardy]
vhardy has joined #fx
21:44:44 [heycam]
ACTION: Dean to make a proposal for feTransform and corresponding canned function
21:44:44 [trackbot]
Created ACTION-61 - Make a proposal for feTransform and corresponding canned function [on Dean Jackson - due 2011-11-10].
21:45:01 [heycam]
DJ: another request that came in was to add more canned effects like lighting
21:45:11 [heycam]
... that was intentionally not put into the spec at the start
21:45:14 [heycam]
VH: they're missing from the spec?
21:45:19 [heycam]
DJ: they're there as markup, not canned functions
21:45:23 [heycam]
... not sure how useful they are
21:45:26 [heycam]
... as shorthands
21:45:42 [heycam]
... one of the disadvantages is that normally it's a tree of lights, writing them in the property you get a big long thing
21:45:49 [heycam]
... one it's annoying to parse, two difficult to animate
21:46:13 [heycam]
CL: usually you want to combine lighting with something else
21:46:23 [heycam]
VH: if we're doing something like this I'd rather have a shorthand for emboss, or chisel, or something like this
21:46:37 [heycam]
CL: right, lighting doesn't do anything by itself
21:46:43 [heycam]
VH: do we do a chisel etc.?
21:46:56 [heycam]
DJ: this is just my feeling, I like the idea of canned ones be very simple and a short list
21:47:00 [heycam]
... it's for the simple case
21:47:12 [heycam]
... go to shaders or markup for anything beyond that
21:47:21 [heycam]
VH: with simple canned filters, if you take a version of a tool like powerpoint, they have a set of canned filter effects
21:47:25 [heycam]
... and those are pretty close to the list you have
21:47:34 [heycam]
... some that apply to images, some that apply to geometry
21:47:42 [heycam]
... emboss, glossy effects are ones that are in tools like this
21:47:53 [heycam]
DJ: I'd be happy a proposal was made
21:48:11 [heycam]
... I think it's easy to add these canned effects, we know how to do them
21:48:12 [heycam]
... the problem is doing it in a way that's readable and understandable
21:48:24 [heycam]
VH: I was thinking one thing would be to have a syntax for custom declarative filters
21:48:31 [heycam]
DJ: that would be very useful
21:48:56 [heycam]
CL: some people are going to just use the keywords, some will write their own thing
21:49:12 [heycam]
... there's a middle ground, the same people who would take a script library but not write it, they'll copy/paste/tweak a fancy filter thing
21:49:20 [heycam]
... from there their css syntax will just be url(...)
21:49:31 [heycam]
VH: could we mark this as an issue for us?
21:52:29 [heycam]
ACTION: Vincent to add an issue for parameter passing into markup filters
21:52:29 [trackbot]
Created ACTION-62 - Add an issue for parameter passing into markup filters [on Vincent Hardy - due 2011-11-10].
21:52:43 [heycam]
DJ: another thing I'll just raise as a potential, though I think we won't do it
21:52:51 [heycam]
... IE5 has the filter property with a bunch of shorthands
21:53:02 [heycam]
... a wave filter, invert
21:53:29 [eric]
eric has joined #fx
21:54:11 [heycam]
Topic: Next F2F
21:54:11 [heycam]
ED: when is CSS meeting?
21:54:16 [heycam]
VH: the next one is in paris
21:54:56 [efidler]
efidler has joined #fx
21:55:09 [Zakim]
-tbah
21:56:14 [shepazu]
http://wiki.csswg.org/planning/2012
21:56:49 [heycam]
VH: for Bucharest in May, Adobe can host an FX day and the SVGWG meeting before/after the CSSWG meeting
21:57:11 [heycam]
... the CSSWG hasn't decided which days exactly
21:57:12 [heycam]
... in the week listed on that page
21:57:26 [heycam]
... typically CSS does 3 days with 1 day of overlap
21:57:43 [heycam]
DS: maybe we can have the WGs meet the same time?
21:57:52 [heycam]
VH: rather not split myself over both
21:58:21 [heycam]
... otoh we could stagger it, meeting over 4 days, have one day of SVG and CSS meeting separately on the same day
21:58:34 [heycam]
... that makes it shorter for those who are going to both
21:59:48 [heycam]
RESOLUTION: We will meet with the CSS WG in May.
22:00:20 [heycam]
ACTION: Erik to coordinate with CSSWG regarding SVG/FX meeting.
22:00:20 [trackbot]
Created ACTION-63 - Coordinate with CSSWG regarding SVG/FX meeting. [on Erik Dahlström - due 2011-11-10].
22:02:00 [Zakim]
disconnecting the lone participant, tpac, in Team_(fx)20:57Z
22:02:04 [Zakim]
Team_(fx)20:57Z has ended
22:02:04 [Zakim]
Attendees were tpac, cabanier, tbah
22:03:15 [heycam]
VH: I think we should either have SVG in Paris in January, or have it several weeks apart in Australia/NZ.
22:04:13 [heycam]
... so CSS is Paris, Feb 6-8
22:04:34 [heycam]
... if we had it earlier than that would be Jan, probably too early
22:04:56 [heycam]
... with the holiday period upcoming, we won't have made as much progress by Jan
22:05:39 [heycam]
VH: my preference is to colocate with CSS
22:05:50 [heycam]
... more efficient travel wise for those attending both
22:05:54 [heycam]
... and good timing between now and May
22:06:16 [heycam]
DJ: also two consecutive Europe meetings
22:06:20 [heycam]
... although CSS is already doing that
22:06:29 [dholbert]
dholbert has joined #fx
22:06:42 [dbaron]
dbaron has joined #fx
22:07:36 [heycam]
VH: we still have a lot of work with requirements, getting the spec together, no lack of things to talk about
22:08:37 [heycam]
CM: I would prefer Aus/NZ in January
22:10:12 [heycam]
... in fact prefer Sydney to Auckland, to maximise dino/danilo chance of attendance
22:12:32 [shans]
http://lca2012.linux.org.au/
22:14:11 [stearns]
stearns has joined #fx
22:14:30 [heycam]
RESOLUTION: SVGWG will meet in Sydney the week of 9 January 2012, deciding exact meeting length later.
22:16:20 [heycam]
Topic: Presentation from Declarative 3D group
22:16:35 [shepazu]
shepazu has joined #fx
22:19:32 [Eric]
Eric has joined #fx
22:20:26 [heycam]
[ Johannes Behr shows some demos ]
22:21:12 [ed]
ACTION: ed to add the decided upon F2F dates to the wiki
22:21:12 [trackbot]
Created ACTION-64 - Add the decided upon F2F dates to the wiki [on Erik Dahlström - due 2011-11-10].
22:26:23 [pdengler2]
pdengler2 has joined #fx
22:28:52 [plinss]
plinss has joined #fx
22:35:11 [heycam]
DJ: is this demo using WebGL?
22:35:23 [heycam]
... in the example where you're adding nodes...
22:35:26 [heycam]
JB: it uses mutation events
22:35:36 [heycam]
... demoing the feature as if you'd extended the browser
22:35:42 [heycam]
DJ: my questions is, is that enough?
22:35:51 [heycam]
JB: there are a couple of things we can't do well
22:36:02 [heycam]
... the big open question is how the material system should look like
22:36:13 [heycam]
... in CSS Shaders, it's got a fixed set of parameters for colour calculations
22:36:23 [heycam]
... in SVG you have filters, but they're all predefined
22:36:33 [heycam]
... with 3D graphics you often want to define something ustom
22:37:29 [heycam]
... native implementations will be much more efficient
22:37:42 [heycam]
... right now, if the CSS transforms changed, I think a native implementations would be better
22:37:52 [heycam]
DS: Google had a proposal a while ago
22:37:55 [heycam]
CM: O3D?
22:38:01 [heycam]
DS: but they eventually went the way of WebGL
22:38:15 [heycam]
... do you know why they decided to abandon their push for O3D?
22:38:42 [dbaron]
dbaron has joined #fx
22:39:23 [heycam]
JB: one reason is that it was sitting in the middle
22:39:30 [heycam]
... this approach sits on one side, declarative
22:40:22 [heycam]
CM: why did the X3D work get a bad reaction in the HTMLWG a couple of years ago?
22:40:32 [heycam]
CL: the old proposal was basically just XML-ized deriviative of VRML
22:40:39 [heycam]
... this new work is much more informed by current W3C work
22:43:23 [stakagi]
I have a comment about the relationship between 3D and SVG.
22:43:30 [efidler]
efidler has joined #fx
22:43:31 [stakagi]
http://svg.mbsrv.net/mapdata/fgdv25000/tokyo/cntr/Cntr02_l3_8-8.svg This is contour map a sort of 2.5D? (no-overhanging 3D?) data by SVG. Contour is well known presentation of 2.5D on 2D canvas for the map.
22:43:42 [stakagi]
Please view source; property lm:(japanese char) describes altitude (in meter). Is the interim data of such 3D and 2D also thought of? This data has the advantage that a common data can be used also by a view by 3D and 2D.
22:51:43 [shans]
shans has joined #fx
22:53:35 [stearns]
stearns has joined #fx
22:53:41 [myakura]
myakura has joined #fx
22:57:19 [shans_]
shans_ has joined #fx
22:59:25 [heycam]
Zakim, code?
22:59:25 [Zakim]
the conference code is hidden, heycam
22:59:39 [heycam]
Zakim, room for 4?
22:59:40 [Zakim]
ok, heycam; conference Team_(fx)22:59Z scheduled with code 26631 (CONF1) for 60 minutes until 2359Z
23:00:49 [Zakim]
Team_(fx)22:59Z has now started
23:00:56 [Zakim]
+tpac
23:01:43 [dbaron]
what's the agenda for after break?
23:02:11 [heycam]
dbaron, a forgotten item of animation
23:02:15 [heycam]
unfortunately dean had to leave
23:02:28 [heycam]
but patrick will be calling in and wants to discuss css animations targetting attributes
23:03:19 [heycam]
Topic: CSS Animation
23:03:51 [heycam]
DJ: [who had to leave earlier]
23:04:15 [heycam]
DJ: Haven't made any progress on any of the animation issues
23:04:48 [ed]
http://www.w3.org/Graphics/fx/track/actions/48
23:05:11 [pdengler2]
calling in one sec
23:05:36 [heycam]
ED: so that is what we decided in Seattle, the action on Dean
23:05:46 [heycam]
Zakim, code?
23:05:47 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
23:05:56 [Zakim]
+ +1.425.868.aaaa
23:06:30 [heycam]
PD: I wanted to ask the group if anyone's in a position to put a stake in the ground about SVG attributes modelled using the attr() thing we discussed, or promoting them to properties
23:06:37 [heycam]
... I kind of wanted to get a sense of their positions
23:06:50 [heycam]
... both WebKit/Firefox can target properties on SVG elements, which is great
23:07:13 [heycam]
... I developed some JS to mimic it in IE, and found it confusing knowing which ones were attributes and which ones weren't
23:07:16 [heycam]
... wanted to get the temperature from other folks
23:08:49 [heycam]
DB: this is putting attr() on the left side of a declaration?
23:08:54 [heycam]
TA: yes, on the property side
23:09:12 [heycam]
PD: yes, but it was very simple
23:09:12 [heycam]
... just to play with it
23:09:38 [heycam]
... [explains how he did that in js to mimic the proposal]
23:09:45 [heycam]
... just to get a feel ancedotally how it works
23:10:00 [heycam]
... Firefox/WebKit target SVG properties
23:10:15 [heycam]
... we (IE) only have it where SVG properties overlap with HTML ones
23:10:20 [heycam]
... independent of SMIL, I think we could do more creative things
23:10:38 [heycam]
ED: one thing dean said before he left, he didn't want to be the gating factor
23:10:44 [heycam]
... he was fine with someone taking the ACTION-48
23:10:48 [heycam]
... and was suggesting Brian to do that
23:11:11 [heycam]
PD: this is what I'd love to do
23:11:15 [heycam]
... I'm happy for someone to go off, do the investigation (again?)
23:11:28 [miketaylr]
miketaylr has joined #fx
23:11:29 [heycam]
... let's decide
23:14:15 [heycam]
CC: could you do something like the data-* that was proposed for CSS recently?
23:14:22 [heycam]
DB: attr-* sounds a bit nicer than attr()
23:14:32 [heycam]
... I think attr() doesn't match the forward compatible grammar
23:15:15 [heycam]
CM: first, should we solve this problem?
23:15:20 [heycam]
DB: yes, just not quite sure how it's going to work
23:15:26 [heycam]
CL: I am concerned about property bloat
23:15:30 [heycam]
... showing up on many elements
23:15:37 [heycam]
... they don't apply to many elements
23:15:56 [heycam]
TA: I'm a bit troubled by allowing something specifically in animations, and not generally
23:16:20 [jen]
jen has joined #fx
23:16:23 [heycam]
CL: if it's seen more as a syntax that pretends an attribute as properties, rather than promoting properties, I'm more conformtable
23:16:28 [heycam]
... less uncomfortable
23:16:41 [heycam]
TA: there are a few conflicts, from the discussion several months ago, where the grammars are a bit different
23:17:01 [heycam]
... I think there are a few cases where the same attribute name are used with different values on different elements
23:17:15 [heycam]
PD: is that such a bad thing?
23:17:19 [heycam]
... we have rules to say how that's resolved
23:17:31 [heycam]
... there are a lot of issue that have come up, there are reasonable calls to make either way you go
23:17:40 [heycam]
... I think it's a matter of committing and going
23:18:35 [dbaron]
dbaron has joined #fx
23:18:50 [TabAtkins_]
As a note - while "attr(): foo;" violates the Core Grammar, it's compatible with the error-parsing rules; the parser will just skip to the next ";".
23:19:14 [dbaron]
yeah, CSS forward compatible grammar doesn't allow anything other than idents on the left side of the : in a declaration
23:21:14 [heycam]
[ discussion about way forward ]
23:22:16 [heycam]
ACTION: Patrick to come up with a concrete proposal for CSS Animations targetting SVG attributes and mail it to public-fx
23:22:16 [trackbot]
Sorry, couldn't find user - Patrick
23:23:15 [Zakim]
- +1.425.868.aaaa
23:23:23 [Zakim]
-tpac
23:23:24 [Zakim]
Team_(fx)22:59Z has ended
23:23:24 [Zakim]
Attendees were tpac, +1.425.868.aaaa
23:51:33 [hober2]
hober2 has joined #fx
00:08:11 [hober]
hober has joined #fx
00:09:47 [ryoichi]
ryoichi has joined #fx
00:19:55 [ChrisL]
ChrisL has joined #fx
00:21:36 [heycam]
RRSAgent, make minutes
00:21:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/03-fx-minutes.html heycam
00:22:00 [heycam]
ChrisL, that worked :)
00:22:26 [ChrisL]
nope, because the lasst thing is
00:22:27 [ChrisL]
CM: a poll?
00:22:27 [ChrisL]
VH: three options
00:22:35 [heycam]
ChrisL, refresh
00:22:36 [ChrisL]
and then the minutes end
00:22:45 [heycam]
(maybe shift+refresh or whatever)
00:22:49 [ChrisL]
oh, right
00:23:02 [ChrisL]
ok, its good
00:23:35 [heycam]
Present: Cameron_McCormack Erik_Dahlstrom Tab_Atkins Doug_Schepers Jun_Fujisawa Sylvain_Galinaeu David_Baron Simon_Fraser Dean_Jackson Timothy_Horton Shane_Stephens Cyril_Concolato Satoru_Takagi
00:23:46 [heycam]
Present+ Jennifer_Yu
00:23:52 [heycam]
Present+ Chris_Lilley
00:24:00 [heycam]
Present+ Rik_Cabanier_phone
00:24:11 [heycam]
Present+ Patrick_Dengler_phone
00:24:15 [heycam]
Present+ Tavmjong_Bah_phone
00:24:48 [heycam]
Present+ Vincent_Hardy
00:25:12 [heycam]
Present+ Eli_Fidler
00:25:23 [heycam]
Present+ Johannes_Behr
00:25:38 [heycam]
Present+ Eric_Mueller
00:25:55 [heycam]
Present+ Alan_Stearns
00:26:12 [heycam]
RRSAgent, make minutes
00:26:12 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/03-fx-minutes.html heycam
01:06:24 [Zakim]
Zakim has left #fx
01:30:51 [dino]
dino has joined #fx
01:41:15 [miketaylr]
miketaylr has joined #fx
02:18:52 [hober]
hober has joined #fx
02:43:05 [thorton]
thorton has joined #fx
04:22:39 [plinss]
plinss has joined #fx