15:59:34 RRSAgent has joined #fx 15:59:34 logging to http://www.w3.org/2011/11/03-fx-irc 15:59:38 Zakim, this is SVG 15:59:38 sorry, heycam, I do not see a conference named 'SVG' in progress or scheduled at this time 15:59:43 Zakim, room for 4? 15:59:44 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 Zakim, code? 16:00:39 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 16:00:57 Team_(fx)15:59Z has now started 16:00:59 +tpac 16:01:46 cabanier, you can call in now ^ 16:02:49 jun has joined #fx 16:05:21 + +1.206.675.aaaa 16:05:23 - +1.206.675.aaaa 16:05:23 + +1.206.675.aaaa 16:05:25 thanks! 16:05:44 plinss has joined #fx 16:06:52 cyril has joined #fx 16:08:15 TabAtkins_ has joined #fx 16:09:27 efidler has joined #fx 16:09:47 RRSAgent, make minutes public 16:09:47 I'm logging. I don't understand 'make minutes public', heycam. Try /msg RRSAgent help 16:09:55 RRSAgent, make minutes 16:09:55 I have made the request to generate http://www.w3.org/2011/11/03-fx-minutes.html heycam 16:10:54 RRSAgent, make log public 16:11:14 Meeting: FX Taskforce at TPAC 2011 16:11:14 Chair: Erik 16:11:15 Scribe: Cameron 16:11:17 ScribeNick: heycam 16:12:23 RRSAgent, this meeting spans midnight 16:13:11 shans_ has joined #fx 16:13:13 efidler has joined #fx 16:13:46 vhardy has joined #fx 16:14:11 dino has joined #fx 16:14:14 jen has joined #fx 16:14:20 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC 16:14:23 Topic: CSS Compositing 16:14:31 Eric has joined #fx 16:14:35 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda 16:14:49 smfr has joined #fx 16:14:56 Zakim, who is on the call? 16:14:56 On the phone I see tpac, +1.206.675.aaaa 16:15:15 ED: we have SVG Compositing, which defines compositing modes for SVG 16:15:16 ... some people have asked to have this apply to CSS/HTML 16:15:18 agenda link again please? 16:15:21 ... we dont' have a spec for that at the moment 16:15:29 thorton has joined #fx 16:15:31 ... in Seattle we decided to investigate it 16:15:43 VH: there is an agreement to have a CSS Compositing spec that would apply to CSS in general 16:15:52 ... and the editors are Rik Cabanier and Alex Danilo 16:15:54 ... but there is no draft yet 16:16:13 The phone connection is very bad 16:16:14 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC 16:16:14 CM: applying to both CSS and SVG? 16:17:01 VH: the plan was to take the SVG Compositing spec, fix it up, and make it also apply to CSS 16:17:15 DJ: this is more of a meta question 16:17:19 http://www.w3.org/Graphics/fx/track/actions/44 16:17:21 ... for SVG Compositing, it seems like the editor was Anthony, who's ... 16:17:25 CC: replaced by me 16:17:30 DJ: do we have implementations of this anywhere? 16:17:38 VH: I think Opera has it 16:17:45 CC: I think the examples in the spec were made with the Abbra player 16:17:54 s/Opera/Abbra 16:18:01 dbaron has joined #fx 16:18:14 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 s/filteres/filters/ 16:18:31 ... when we've talked to developers who want compositing, they just want e.g. "screen mode" that photoshop can do 16:18:40 ... people rarely want to use the porter-duff modes 16:18:44 s/dev/content dev/ 16:19:13 sylvaing has joined #fx 16:19:15 ... 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 ... not that they don't exist, but not many people are asking to be solved 16:19:32 ... in the Compositing spec there's also stuff about clipping to self etc., which makes it more difficult 16:19:40 Rossen has joined #fx 16:19:57 ... 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 ... 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 VH: even if you do it with filters you'll need background access 16:20:49 ... you need something like the BackgroundImage in the filters spec 16:21:19 DJ: which is going to be a difficult thing to support now 16:21:26 ... 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 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 ... it's not like they have a predefined image 16:22:13 ... I haven't seen them use porter-duff much, but artists use "add" 16:22:19 Looking at how people use compositing today in Flash and PDF. it is a very commonly used algorithm. 16:22:27 CM: and you see them blend on to the background? 16:22:28 VH: yes 16:22:30 I agree that we don't see much point to PD 16:22:34 ... they do this in flash too, where it's available 16:23:11 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 ... I thought there was a group that really wanted to see PD 16:23:17 If Porter-Duff were included, could "source" and "dest" be spelled out rather than being src and dst? 16:23:45 For example: http://fluid.nl/ (look at Space Collective) 16:24:13 DJ: what is the status of the spec? 16:24:30 VH: for SVG Compositing, we had Anthony and Alex being the editors 16:24:33 ... not active lately 16:24:51 ... we have editors who were willing to take on the work but had limited bandwidth to do so 16:24:58 stearns has left #fx 16:25:12 ... 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 CC: I can contribute to the editing of this spec, for sure 16:25:20 ... I'd like to understand the problem with the background 16:25:23 ... is it just enable-background? 16:25:52 DJ: setting it to new is good, but let me talk about how apple/webkit composite 16:26:13 ... 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 ... 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 SF: imagine a div that has webgl under half of it, and something else on the other half 16:26:41 ... you have to flatten the webgl and the other thing into a texture, then read it back 16:27:22 ... 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 ... 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 CM: so difficult but not impossible? 16:27:57 DJ: it's not that everything is not on the gpu 16:28:15 ... imagine you're trying to composite over a page element where something is in webgl and another is filtered 16:28:19 ... you've done this on the gpu to composite them together 16:28:44 shepazu has joined #fx 16:29:02 RC: but that's just a webkit implementation 16:29:14 ... you could do it with pixel shaders right? 16:29:14 DJ: it's possible 16:29:24 CC: in acrobat we have hardware acceleration where everything is composited in the gpu, including blend modes and masks 16:29:28 s/CC/RC/ 16:30:01 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 ... it's basically an alternate order to your source mode 16:30:26 SF: it's not impossible for us to do this, it's just hard 16:30:30 stearns has joined #fx 16:30:43 EF: on mobile we have severe constraints with the gpu 16:30:52 ... so we can't put everything in a texture 16:31:11 ... you would normally have one big base layer that is not in a texture 16:31:40 ... 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 ... 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 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 EF: yes, and we can't do that due to resource constraints 16:32:26 CC: two issues, performance, and the use cases 16:32:44 ... performance issue we could put restrictions, this number of textures, that's one thing 16:32:52 ... but we should see what are the use cases that could be accommodated with these restrictions 16:33:11 ... I hear also that PD might not be the best modes 16:33:11 ... we have some use cases for PD 16:33:26 ... 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 ... even if the scope is broader, it applies to HTML, keeping the use cases for SVG is important 16:33:54 ACTION: Cyril to provide use cases for blend modes 16:33:54 Sorry, couldn't find user - Cyril 16:34:34 paul_irish has joined #fx 16:34:48 VH: with PD, you never need to read background 16:34:53 ... blend modes do need to, though 16:35:26 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 has joined #fx 16:35:46 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 has joined #fx 16:35:53 CC: if you set enable-background:new, you forget what was on the bg 16:36:13 ... 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 DB: what if there's opacity? 16:36:29 VH: enable-background:new is like creating a new surface 16:36:37 DB: I know how that works with filter effects 16:36:54 VH: compositing operators are like shorthands for filter affects 16:36:57 s/affects/effects/ 16:37:48 dom has joined #fx 16:37:49 DB: one other comment from a CSS perspective is that keywords tend not to be abbreviated like "src" and "dst" 16:37:55 ... at least they would be "source" and "dest" 16:38:13 DS: I think most people would understand 16:38:15 PL: I think those abbreviations are common in the graphics world 16:38:40 http://www.w3.org/TR/SVGCompositing/#enable-background-property 16:38:49 SF: canvas has "source-atop" 16:38:55 DB: that feels more CSS-like 16:38:57 canvas: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing 16:39:02 ... but maybe I'm just used to it from canvas 16:39:13 DS: isn't this a similar problem to why SVG doesn't have z-index? 16:39:34 SF: doesn't SVG behave like every element is a stacking context? 16:39:36 VH: yes 16:39:44 ... the model is any group, you render the group, then composite it with the parent 16:40:13 CC: I think we need to first make sure this is implementable, even on gpus and on mobile with reasonable performance 16:40:25 VH: I would say the implementability is not a question, because we know filters are implemented 16:40:32 ... and largely compositing is a shorthand for filters 16:40:48 ... it might not be optimal and efficient though 16:40:57 CC: we might need to make changes to the spec to allow efficient implementations 16:40:57 correct. and we know compositing is working well on mobile devices since Flash is alreayd using it 16:41:06 on those platforms 16:41:27 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 enable-background is the one that might make things slow 16:41:30 ... I'd like to avoid that if possible 16:41:59 but there are tricks to avoid it in most cases 16:42:00 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 ... the thing that has been questioned is PD rules 16:42:14 ... coming back to the WG with use cases is good 16:42:35 ... 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 SF: I do agree that we need input from implementors, don't know when we'll get that 16:44:15 CM: are the blend modes useless without being able to read the background? 16:44:15 VH: yes 16:44:28 ... you do too for src-over, since there's opacity, but that's already supported 16:44:40 SF: I'm confused by enable-background 16:44:54 ... it could use a better name 16:45:15 DB: who implements BackgroundImage? 16:45:15 Adobe calls it isolate group 16:45:16 ED: Opera, Batik, ASV 16:45:29 DB: I don't how they interact with other features, but that's a separate conversation 16:45:31 an isolated group = background: false 16:45:42 VH: I think the CSS rendering context is different, how does that work with stacking contexts 16:45:46 ... SVG is pure painter's algorithm 16:45:51 non-isolated = enable-background: true 16:45:57 DB: if this were added to HTML, then enable-background would need to force a stacking context 16:46:16 s/ASV/ASV, IE10/ 16:46:19 SF: it behaves like non-1 opacity 16:46:19 DB: transforms do the same thing 16:46:45 VH: enable-background is not simple 16:47:15 CC: on the question of implementability, it's difficult but possible? 16:47:16 VH: Adobe has implemented gpu accelerated blend modes 16:47:20 ... using pixel shaders 16:47:45 SF: I think HTML/CSS is more complex, we have video and WebGL which makes it harder 16:47:53 DJ: video's a good example of not having access to those pixels 16:48:00 flash has it in hardware too but they don't have enable-background 16:48:40 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 ... in your app you won't have access to video frames 16:48:52 that problem would apply to filters as well. They would need access to the video pixels 16:48:59 ... it may not have the ability to do filters etc. 16:49:14 VH: that means the issue you're facing is true for compositing but also for filters 16:49:45 CC: we also need more reports from implementations, nailing down the exact issues that might be impossible 16:50:00 VH: since the issue is really background access, I think this is something we're going to hit pretty soon 16:50:14 ... we have one data point from MS 16:50:18 ... are the filters in IE10 supported on mobile? 16:50:29 JY: don't know 16:50:39 VH: it would be great data to know, for implementability, on mobile 16:50:58 JY: I could find out 16:51:23 ACTION: Jen to find out whether filters with enable-background are implemented on mobile 16:51:23 Sorry, couldn't find user - Jen 16:52:19 dom has joined #fx 16:52:27 SF: we might figure some of this out while we're doing Filter implementations 16:52:32 VH: we will hit this with shaders as well 16:52:44 ACTION: Vincent to look into implementability of blend modes 16:52:44 Created ACTION-54 - Look into implementability of blend modes [on Vincent Hardy - due 2011-11-10]. 16:52:55 CC: could we remove enable-background? 16:52:56 ED: that's one option 16:53:13 ... we could split the parts we don't want out, or have two conformance classes 16:53:13 SF: I hate conformance classes 16:53:17 VH: also blend modes, they need to composite with something 16:53:29 ... in the filter you could say you don't have BackgroundImage, but for compositing you need it 16:54:19 ... for filters there are certainly things you can do without BackgroundImage 16:54:47 ED: let's wait for feedback then 16:54:54 VH: what does Opera do for mobile? 16:54:58 ... for mini, we render on the server 16:55:11 ... but it sends a raster back 16:55:12 ... for mobile, we do the same implementation as for desktop 16:55:20 ... it does render filters, if the hardware is not good, it won't have the best performance 16:55:22 ... but it's the same code 16:55:38 s/... for mini/ED: for mini/ 16:56:22 CC: should we record the issues in the spec? 16:56:25 VH: yes, wouldn't hurt 16:56:40 ACTION: Cyril to record implementability concerns in the Compositing spec 16:56:40 Sorry, couldn't find user - Cyril 16:57:47 Topic: clip-path and mask in HTML 16:58:00 ED: I had an action to make clip-path and mask apply to HTML content 16:58:28 ... it's already implemented in Firefox 16:58:30 https://developer.mozilla.org/en/CSS/clip-path 16:58:35 https://developer.mozilla.org/en/CSS/mask 16:58:40 ... my action was to move the definitions of those properties, and make it work, to the Filters spec 16:58:50 ... 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 ... my question was, wouldn't it be a better match to put it in the compositing spec instead? 16:59:13 CC: it's also an editing question for the SVG spec 16:59:15 ED: it's not somethign that's in the filter chapter currently 16:59:21 s/somethign/something/ 16:59:27 VH: would it be more natural to have a CSS Masking & Compsiting spec? 16:59:32 ... it would be one more spec 16:59:36 s/Compsiting/Compositing/ 16:59:42 ... it's a different place in the rendering pipeline 16:59:49 CC: does WebKit support it? 16:59:52 SF: we have two mask properties 17:00:15 ... one is equivalent to background-image, the other equivalent to border-image 17:01:01 Webkit's mask is more of a softmask. It 17:01:04 is not a clip 17:01:21 AS: it's the luminance from the resulting image that is the mask value 17:01:37 SF: my reaction to these two properties, re clip-path is similar to CSS clip, which already take as rectangle 17:01:43 ... it would be nice to do that without SVG 17:01:49 ... giving the path in the property 17:01:54 ... kind of ugly, but we might want that 17:02:02 ... with mask, we found the need to do this 9-piece image thing 17:02:15 VH: is that in a spec? 17:02:15 SF: no 17:02:25 ... 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 http://www.webkit.org/blog/181/css-masks/ 17:03:50 CC: would IE like it? 17:03:51 https://developer.mozilla.org/en/CSS/-webkit-mask-box-image is the border-image equivalent 17:03:55 JY: seems like something that would be useful in general 17:03:59 ... curious if people are asking for it though 17:04:13 SG: in the abstract, it sounds useful, use cases would be helpful 17:04:17 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 ... that's how you get the alpha dropoff in reflections 17:04:31 Very useful for us. We used it but it was very fragile. 17:04:32 ... would be nice to provide enough properties that they could do this themselves 17:04:42 DJ: typically with a gradient 17:05:00 ED: you could do it with filters, the thing that would be hard is transforms 17:05:18 CC: how do we move forward on this? 17:05:33 ED: I have an action to put it into the Filters draft, but I think it's the wrong place 17:05:38 VH: I vote for creating a new draft 17:06:02 SF: I don't care where it goes, but CSS clip should go along side these things 17:06:15 VH: your point is to make these things work together 17:06:27 SF: I would like to see the properties converge 17:06:42 PL: that's why the CSS clip property took a rect() value 17:06:45 ... so it could be extended later 17:07:12 Peter is suggesting clip: path(...) or similar 17:07:23 CM: I don't think people use clip and clip-path 17:07:38 ... we could have them be aliases or something 17:07:48 ED: nobody uses clip in SVG content, since it's broken 17:07:52 JY: the definition changed between CSS20 and CSS21 17:08:44 http://www.w3.org/TR/SVG/masking.html#OverflowAndClipProperties 17:09:28 DB: In CSS 'clip' only applies to absolutely positioned elements 17:09:43 VH: In SVG it only applies to elements that establish a new viewport (e.g., svg, image) 17:10:11 http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports 17:10:49 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 SF: we would need to extend clip so that it applies not just to SVG viewport creating elemetns 17:11:13 ... the other thing, for css, is to define how clip and masking affect hit testing 17:11:28 ... I forget if CSS clip makes elements transparent to hit testing? 17:11:38 DB: we don't define that properly, but it should affect hit testing 17:11:41 SF: is the same true of masking? 17:11:52 ... we've talked about extending pointer-events to look at alpha 17:12:13 ED: in SVG, clip-path you do get clipping of events 17:12:23 ... but for masks it's treated as a raster, and just a rectangle 17:13:42 http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty 17:13:53 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 TA: wonderful question. I would assume that non-united values would work, and map into CSS pxs 17:14:13 ... but also allow normal CSS units in there 17:14:19 SF: do you really want to have a path that has mixed units? 17:14:22 TA: maybe it's useful? 17:14:28 DB: there are plenty of existing things that are a bad idea 17:14:30 SG: let's add more! 17:14:36 SF: CSS rect() doesn't have units? 17:14:37 DB: it does 17:14:46 ... mixing CSS units between different properties is a bad idea already 17:14:57 ... specifying one box's width in ems and aligining it with another that's in px is not going to work 17:15:15 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 DB: pretty much 17:15:15 TA: you can do that in gradient definitions too 17:15:21 DB: I wouldn't want to forbid other units in a path 17:15:33 SG: there's a difference between mixing them, and using the same unit across the whole path 17:15:42 TA: the problem is that, we could potentially say to use the same units across the path 17:15:49 ... that wouldn't be difficult, don't see a lot of use for it though 17:16:11 DB: I also think there are probably useful for different units in paths 17:16:11 ... esp with relative units 17:16:15 ... one unit in one dimension, and another in the other 17:16:22 VH: or if you want to align things you've done on the page 17:16:32 SG: if you have relative units, and your path changes based on font size, that's weird 17:16:34 ... but could be interesting 17:17:15 VH: the pre-1.0 draft of SVG had units in there 17:17:26 ... if you specified a stroke-width of 5px, that would be non-scaling 17:17:28 CC: device pixels? 17:17:29 VH: yes 17:17:45 ... and that was taken about 17:18:38 ... we will have this in transforms, too 17:18:45 ... so it might make sense to bring it up as a general issue 17:18:55 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 created http://www.w3.org/Graphics/SVG/WG/track/issues/2428/ 17:19:33 (without the slash on the end) 17:19:37 VH: so we'd need to find editors for this 17:19:58 CC: do we want to resolve on creating a new spec? 17:21:02 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 DS: so currently you need to reference a clipPath element in SVG 17:21:18 TabAtkins_ has joined #fx 17:21:19 ... have we talked about relaxing that? 17:21:27 SF: I mentioned the desire to have a path directly in the CSS 17:21:38 DS: I meant more referencing an SVG , rather than a 17:21:48 VH: I think we should 17:21:52 ... it's the same problem with Exclusiosn 17:21:59 ... we want to reference geometry 17:22:12 s/Exclusiosn/Exclusions/ 17:22:35 ACTION: Erik to write up a spec for clip/mask in SVG/CSS 17:22:35 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 has joined #fx 17:25:26 -- 15 minute break, return at 10:40 -- 17:29:59 plinss has joined #fx 17:33:26 trackbot, bye 17:33:26 trackbot has left #fx 17:33:29 trackbot has joined #fx 17:33:33 trackbot, list users 17:33:33 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 trackbot, status 17:34:39 dom, are you able to add Jennifer Yu to tracker's list of FX people? 17:38:28 Zakim, code? 17:38:28 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), shepazu 17:38:43 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 cabanier, then you'll have to call back in (sorry) 17:39:11 -tpac 17:39:21 Zakim, who is on the call? 17:39:21 On the phone I see +1.206.675.aaaa 17:39:26 Zakim, hang up +1 17:39:26 I don't understand 'hang up +1', heycam 17:39:31 Zakim, help? 17:39:31 Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help. 17:39:34 Some of the commands I know are: 17:39:35 xxx is yyy - establish yyy as the name of unknown party xxx 17:39:37 if yyy is 'me' or 'I', your nick is substituted 17:39:40 xxx may be yyy - establish yyy as possibly the name of unknown party xxx 17:39:43 I am xxx - establish your nick as the name of unknown party xxx 17:39:46 xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group 17:39:48 xxx also holds yyy - add yyy to the list of participants in group xxx 17:39:51 who's here? - lists the participants on the phone 17:39:54 who's muted? - lists the participants who are muted 17:39:57 mute xxx - mutes party xxx (like pressing 61#) 17:39:58 Zakim, drop +1 17:39:59 unmute xxx - reverses the effect of "mute" and of 61# 17:40:02 is xxx here? - reports whether a party named like xxx is present 17:40:04 list conferences - reports the active conferences 17:40:05 this is xxx - associates this channel with conference xxx 17:40:08 excuse us - disconnects from the irc channel 17:40:09 I last learned something new on $Date: 2010/03/15 18:49:04 $ 17:40:11 - +1.206.675.aaaa 17:40:11 Team_(fx)15:59Z has ended 17:40:12 Attendees were tpac, +1.206.675.aaaa 17:40:14 sorry, heycam, I don't know what conference this is 17:40:20 pdengler has joined #fx 17:40:24 Zakim, room for 4? 17:40:25 ok, heycam; conference Team_(fx)17:40Z scheduled with code 26631 (CONF1) for 60 minutes until 1840Z 17:40:31 Team_(fx)17:40Z has now started 17:40:37 + +1.206.675.aaaa 17:40:57 Zakim, code? 17:40:57 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 17:41:07 +[Microsoft] 17:41:10 - +1.206.675.aaaa 17:41:11 + +1.206.675.aaaa 17:41:18 +tpac 17:41:29 Zakim, aaaa is cabanier 17:41:30 +cabanier; got it 17:42:13 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC 17:43:00 Topic: Transforms 17:43:13 jun has joined #fx 17:43:27 thorton has joined #fx 17:43:32 ED: first issue is unification of CSSMatrix/SVGMatrix 17:43:51 DJ: the general topic is that SVGMatrix has been around for a while, but it only supports 2D transforms 17:44:03 ... and CSSMatrix we found we needed to add a Matrix API for CSS transforms, which supports 3D 17:44:13 ... it's a bit unusual that there's two matrix classes 17:44:17 ... recently there was a proposal to add an immutable matrix class 17:44:22 ... people are doing lots of math in their JS code 17:44:34 ... and copying these matrix objects around is making things slow 17:44:41 CL: so would you be able to instantiate a 3D matrix from a 2D one? 17:44:54 DJ: the main thing we're asking for is being able to do .scale(2) and return a new object 17:45:13 ... creating one from the other is not as big a deal 17:45:15 jen has joined #fx 17:45:28 ... 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 ... secondly, those APIs should be immutable matrix, so that you don't have to do lots of JSgarbage collection 17:45:56 s/immutable/a mutable/ 17:46:02 efidler has joined #fx 17:46:14 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 DJ: we thought about this multiple times, never came up with a good solution 17:46:32 ... maybe translateInPlace(), but that looks terrible 17:46:35 ... so not sure 17:46:52 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 ... not extending existing APIs, but adding a new one 17:47:13 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 ... since you can't return the same thing twice 17:47:21 ... I don't know if that matters 17:47:31 ... depends what the APIs that return a matrix are 17:47:37 ... with immutable matrices, you can return new ones 17:48:11 CM: you can still write to SVGMatrix's a, b, c, etc. 17:48:12 ... even if the methods return new objects 17:48:15 s/you can/you don't have to/ 17:48:20 ... so I think implementations don't have that optimization atm 17:48:59 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 trackbot, status 17:49:30 DJ: mutable and immutable on the same object? 17:49:30 trackbot, status? 17:49:32 CL: that would allow avoiding serialising/reparsing 17:49:50 trackbot, bye 17:49:50 trackbot has left #fx 17:49:52 trackbot has joined #fx 17:49:56 trackbot, status? 17:50:01 DJ: we should design it with the idea that it could be used in WebGL? 17:50:22 CL: the declarative 3D people want to come up with new JS types for matrix etc. 17:51:16 CL: is there a concrete proposal? 17:51:23 DJ: there's one in the stage of going from liquid to solid 17:51:30 ... there's been a message on the webapps mailing list 17:51:56 SF: a question for implementors who implemented CSSMatrix 17:51:59 ED: opera does 17:52:00 SG: we have 17:52:14 ED: but you can't construct those objects 17:52:15 SF: is the IE implementation exposed to JS? 17:52:16 SG: yes 17:52:19 SF: prefixed? 17:52:19 SF: yes 17:52:25 s/SF/SG/ 17:52:36 SF: so this would be an evoluation of the CSSMatrix? 17:52:38 DJ: yes 17:52:52 ACTION: Dean to propose a unified Matrix for SVG/CSS 17:52:53 Created ACTION-56 - Propose a unified Matrix for SVG/CSS [on Dean Jackson - due 2011-11-10]. 17:53:17 ACTION-56? 17:53:17 ACTION-56 -- Dean Jackson to propose a unified Matrix for SVG/CSS -- due 2011-11-10 -- OPEN 17:53:17 http://www.w3.org/Graphics/fx/track/actions/56 17:53:54 edited the action 17:54:01 DJ: the other part of the issue is the unification 17:54:15 ... now if you want to add 3D transforms to SVG, what do we return? 17:54:45 ... given the SVG spec for 10 years has said element.transform you can get an SVGMatrix in there 17:54:52 ... with this combined transform spec, we have 3D transforms 17:55:14 CM: so whether we should double up on all these methods on a unified matrix? 17:55:46 VH: so let's have this as an issue to resolve in the spec 17:56:41 DJ: so this is a bit of a hack, because in the 2D spec we define CSSMatrix 17:56:47 ... and in the 3D spec we define CSSMatrix 17:56:50 ... and they're different 17:56:52 ... the 3D only adds 17:57:24 ... 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 ... and without doing something like having rules like "if it's a 2d transform, return an SVGMatrix" 17:57:43 JY: aren't we rehashing the SVG DOM anyway? 17:57:48 DS: yes 17:58:20 CM: we might break some existing stuff 17:58:28 ... not sure 17:58:31 ED: I don't think the risk is that high 17:59:15 Eric has joined #fx 17:59:17 CM: there's a,b,c,d,e,f and m00, etc. 17:59:26 DJ: the former are on both SVGMatrix and CSSMatrix, the latter are only on CSSMatrix 17:59:51 CM: I assume then we're not going to get rid of a,b,c etc. 17:59:52 DJ: no 18:00:19 VH: I think this is tractable 18:00:19 ... the two fields map to the same values 18:00:34 CM: it's not a huge deal to keep both set of methods either 18:00:55 VH: the Tiny DOM has immutable versions of methods 18:00:57 ED: yes 18:01:02 s/immutable/mutable/ 18:01:16 VH: I took an action at the last FX meeting to maek a draft of the merged spec 18:01:25 ... under the dev repository there's a transforms spec 18:01:28 http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix 18:01:29 http://dev.w3.org/csswg/css3-transforms/ 18:01:53 ... so that spec is just 2D transforms, trying to converge with SVG 18:02:00 ... I will try to get that spec to be a merged 2D SVG/CSS spec first 18:02:03 ... then worry about 3D later 18:02:21 ... that's the only update I had 18:02:25 DJ: do we want to publish what we have? 18:02:43 SG: we have these two specs on CSS, and having them at the same time, is a bit weird 18:03:21 SF: I think we also resolved to publish newer WDs of CSS 2D transforms 18:03:31 ... but I agree with SG that we should cut over at the same time to the merged spec 18:03:54 ACTION: Vincent to make clear in the merged transforms spec that it hasn't yet replaced the separate specs 18:03:54 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 [ discussion of which/whether/when CSS and merged transforms specs get published ] 18:09:55 plinss has joined #fx 18:11:15 cyril has joined #fx 18:15:00 [ concern about 3D holding 2D merged spec back ] 18:15:26 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 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 ED: who will do the merging of 3D? 18:17:40 VH: Simon, Dean and myself 18:18:31 s/CSS 2D and 3D/CSS 2D and CSS 3D/ 18:19:31 RESOLUTION: We will republish the SVG Transforms module to obsolete it. 18:19:42 ACTION: Cyril to prepare SVG Transforms module for obsolescence. 18:19:43 Created ACTION-58 - Prepare SVG Transforms module for obsolescence. [on Cyril Concolato - due 2011-11-10]. 18:20:19 Topic: CSS Shaders 18:20:28 VH: I can show a demo 18:21:45 [ Vincent shows a demo/presentation of CSS shaders ] 18:23:36 CC: so you having picking there? 18:23:37 VH: no 18:23:43 CL: that's going to be confusing, and limiting 18:23:47 VH: we're working on that issue 18:24:01 ... let's get back to that issue later 18:25:28 dbaron has joined #fx 18:26:00 [ demo continues ] 18:29:02 trackbot, status? 18:29:14 trackbot, bye 18:29:14 trackbot has left #fx 18:29:16 trackbot has joined #fx 18:29:23 trackbot, status? 18:38:01 [ 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 VH: summary of where we stand 18:38:25 ... the patch is available 18:38:36 ... the main issue we've had is the shader language requirement 18:38:45 ... there have been security concerns expressed 18:38:54 ... and questions on filter margins 18:38:59 ... and pointer events handling 18:39:19 ... for the shader language, it's a key decision 18:39:27 ... agreeing on one thing will allow content to have just one shader 18:39:38 ... otherwise we'll end up in the same situation than audio/video 18:39:44 ... which is actually worse, since we're talking about code 18:39:51 ... people will need to write shading code twice 18:39:59 ... unless there's a way to transcode 18:40:14 ... that's a requirement, and orthogonal to the one we picked 18:40:14 ... there are only so many solutions here 18:40:26 ... we pick an existing shading language or we invent a new one 18:40:43 ... maybe a better language comes up in the future 18:40:53 ... at adobe we have pixel bender, another shading language 18:40:57 http://xkcd.com/927/ 18:41:13 ... 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 ... and it'd cause fragmentation 18:41:33 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 ... something people can participate in 18:41:44 SF: I think there's also a benefit from choosing a language there's existing content for 18:41:52 DS: something that's used commonly in open source 18:42:12 DJ: the other big thing is WebGL, speaking for GLSL as a shading language 18:42:12 VH: the current draft recommends we converge on GLSL 18:42:28 ... the question is to allow other languages, and have a type attribute to select 18:42:41 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 ... like