<Cyril> scribe: Cyril
heycam: Tagaki-san has a demo in WebKit
(takagi-san presenting)
birtles: 1st performance demo: zooming by changing the viewbox
... 2nd demo, Bitmap in Canvas and zooming
... same with panning
heycam: is that using the zoom and pan feature that some don't implement
AlexD: no, this is using scripting
heycam: if it was using built-in, then the application could choose
krit: WebKit has built-in zooming and panning
heycam: I meant the built-in interaction on the root element
... but it would be equivalent to controlling currentScale ... by script
birtles: is that optimized in any UA?
heycam: probably not
... but this would be easier to optimize than the viewbox scripting
AlexD: performance difference between redrawing the entire tree vs. bitblitting a bitmap around
ed: we optimize that in Opera
AlexD: lazy redraw
ed: a viewbox change does mean you have to redraw everything
heycam: it changes %
AlexD: most implementation will say the root is dirty
ed: you could work out that it is a scale transform
AlexD: but that is very specific
birtles: you probably want to do a perf comparison vs using a transform
... the second case is how you can create a Canvas
AlexD: that is very close to buffered rendering
krit: internally you do viewbox with a transform, so what's the difference ?
AlexD: you'd have to add logic to detect that the transform does not need a whole redraw
shane: doing that without doing a Canvas would be to use CSS 3D Transforms
... changing the perspective via CSS will treat the SVG as an image
krit: in browser we have the backing store but it's not in the rendering layer
shanestephens_: CSS Transforms will do go performance
AlexD: if you'd have buffered rendering on the root and CSS 2D Transform (not accelerated) you'd generate a bitmap
<stakagi> how you can create canvas : http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda/Performances_to_transition_in_zooming_and_panning#Existing_implementation
AlexD: if you're doing that in Script, you're synchronous
... but you want the zoom to be independent of the scripting
heycam: they couldn't say scale the bitmap and when there is a free cycle, render the rest
AlexD: as long as the zoom is handled by the UA and not the script, you'd have no problem
... with script as part of the web content, they block each other, because the DOM is single threaded
shanestephens_: Tab has a proposal
cabanier: some people objected
shanestephens_: yes objected because not a priority at that time
birtles: we've seen that there are other ways to render faster than using canvas
... but the second issue is: is it still useful to be able to render SVG within a Canvas ?
... there is a section in the proposal
... it shows one way people are doing it now
... by serializing SVG out, and giving that to a Canvas
... which is not very elegant
... is it worth pursuing a more elegant way
heycam: you can't get the pixels out of the canvas
... and I'm a bit surprised, data URI shouldn't taint the canva
krit: it's because it's SVG and SVG can have links ...
... and you could check visited links ...
AlexD: there is a security reference in the paper
<AlexD> See http://www.svgopen.org/2010/papers/62-From_SVG_to_Canvas_and_Back/index.html
<cabanier> link: http://www.svgopen.org/2010/papers/62-From_SVG_to_Canvas_and_Back/index.html
shanestephens_: I don't understand how the proposed methods are safer
heycam: It doesn't claim to be safer ?
... most uses of that would look at the rendering
... access to the pixels
krit: browsers have logic to prevent access to unwanted pixels
... they don't do it in an interoperable way
... Firefox don't show links (in black), links are not links anymore
cabanier: sounds like a bug in Firefox
AlexD: is there a reason that currentTranslate is read-only
ed: you can modify the inside (currentTranslate.x)
AlexD: so you should be able to use them with good performance
shanestephens_: it seems that if we remove the restriction on getImageData, that would make it easier
Cyril: is there a way to know that the data URI was generated
heycam: no
Cyril: maybe a blobURI could be used
cabanier: you could use drawImage with SVGSVGElement
... it would be easier
ed: yes we support it
heycam: about the links in Firefox, the default styles are not applied but if you have your own :link, it works
... so it looks like a bug
ed: I did propose drawImage (SVGSVGElement) but it was not accepted
... there are some undefined things
krit: Opera doesn't style visited links
ed: mixing foreignObject and nesting can be tricky
krit: svg + foreignObject + html in Firefox works, and Opera (with problems)
<krit> and not at all in WebKit
heycam: how do you size the SVG element ?
ed: the drawimage can provide the area but not always, that's a problem
krit: same thing as img with no width and height attribute, Firefox uses a default size
... we could have that for SVG
birtles: I thought this was specified in CSS Image Values and Replaced Content
<birtles> http://dev.w3.org/csswg/css3-images/
birtles: at the end of the proposal, there is text to create the image
krit: (reading a note in the CSS images)
heycam: the proposal is not clear about whether createSVGimage is meant to create a rasterized image or an independent clone
... with styles
Cyril: the note says for animation it is uncertain, so it sounds like a snapshot more than a clone
heycam: you need to snapshot the computed style of the SVG elements in the tree that you are cloning
... erik, do you think the Canvas spec should allow drawing with SVGSVGElement
ed: yes, but with security constraints
... and we need to define the behavior of transforms
... I've seen cases of SVG being pixelated when drawn
krit: the Canvas spec has been changed regarding the zooming
cabanier: maybe you should propose it again and see what happens
heycam: it seems that people would rather have drawImage with SVGSVGElement support than a new method
<scribe> ACTION: ed to propose drawImage with SVGSVGElement to the public canvas mailing list
<trackbot> Created ACTION-3435 - Propose drawImage with SVGSVGElement to the public canvas mailing list [on Erik Dahlström - due 2013-02-12].
heycam: if you drawImage an image element with animated content in it, does it snapshot ?
cabanier: it should
ed: we snapshot at t=0
AlexD: use the snapshotTime from Tiny
<birtles> looking up default sizing: CSS 2.1 sets width:auto to 300px when it can't be determined (http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width) and height to 150px (http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height)
<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/NonScalingObject
birtles: this is following from an action from the last F2F
AlexD: this is constrained transformed, isnt it?
heycam: do we have transform="ref" in SVG
ed: not yet, but adding it just to SVG 2 (not CSS Transform) is hard
... is it useful outside of SVG 2
AlexD: yes, itcan be useful in general for Webapps
Cyril: I don't understand the example with text
krit: there is a flowing/exclusion thing
Cyril: ok the text hasn't changed font size but since the shape has increased, you can fit more text in it
shanestephens_: sounds like this makes constrained transforms more complicated
birtles: we discussed some things related yesterday
Cyril: flip invariant text
heycam: pinned transforms
krit: should we look at 1.1 for the next version of CSS Transforms
heycam: 1.1 is change the position but not the scale
Cyril: that's pinned transform
birtles: there are 5 cases in section 1
... case 1 is regular scaling
... case 2 is non scaling stroke
case 3 is non scaling objects
scribe: case 4: there is a difference between scaling the content vs the viewport
heycam: I don't understand this one
shanestephens_: I think case 4 is like case 1 (current behavior)
<stakagi> 1.2 is pointed out by alex three years before
shanestephens_: case 5 is the same as case 3 but rather than the CTM being changed it is the viewport being changed
heycam: one is scaling because of hte transform stack and the other one is the viewbox thing outside of the transform
... the requirement could be set in the same way for both things: changing the aspect but keep the positing
... for cases with UI control, whatever the positioning and scaling mechanism used, it should be on the content and on the UI
... the UI should be in a different element
... so that you don't have to undo the transform on the UI stuff
ed: maybe it's because in Tiny you can't nest SVG elements
heycam: if currentTranslate and currentScale don't work on inner svg elements, we should make it work
... for POI element, it's a different story, because it's part of the content
... it's a valid use case
<scribe> ACTION: shane to investigate the model for constrained transforms
<trackbot> Created ACTION-3436 - Investigate the model for constrained transforms [on Shane Stephens - due 2013-02-12].
<scribe> ACTION: shane to investigate currentTranslate and currentScale on inner svg elements
<trackbot> Created ACTION-3437 - Investigate currentTranslate and currentScale on inner svg elements [on Shane Stephens - due 2013-02-12].
heycam: currentTranslate and currentScale can be modified by script but are also affected by the user transforms
birtles: case 4 and case 5 if you resize a window that contains SVG, the viewbox to viewport ratio is adjusted and this is not accessible in the DOM
... case 5 is for when you resize the window, you want some objects not scaled
<stakagi> In other words, 1.2 case 5 can be said fixed size in physical unit.
heycam: you wouldn't want to specify physical units because they are not really physcial unit
... you want the initial size to remain the same after interaction
... what about section 2 items
birtles: I think shane will look at it in his actions
shanestephens_: partly
... there are more issues than constrained transforms
... there are some layout issues
heycam: 2.1 you could do media queries and switching
birtles: if you have suitable media queries
heycam: do they exist?
birtles: no, there is the proposal for zoom
heycam: what about the picture element
birtles: the thing that was showed was part of the iframe proposal not of the picture element
heycam: with max-zoom, min-zoom media queries you could probably do it
shanestephens_: would you be able to do it with foreign content
... and text overflow
heycam: we've made text overflow work on text in SVG
shanestephens_: overflow of boxes in CSS is different
... the spirit of that proposal is automatic change of text
... my concern with media queries, you'd need to guess where the swithc points should be and that'd be hard to do
... but the browser knows the switch point
... but just displaying "Sydney in" would not be good either
birtles: I suspect media queries could do a reasonnable job for now
shanestephens_: media queries could produce the wrong results
heycam: if you don't know the exact font
shanestephens_: and script might be better
... I don't think we should add new features for now
heycam: solving as part of extending text overflow seems to be right approach
shanestephens_: hard things are hard
heycam: (showing a tool to produce adpative diagrams)
--- break ---
<nikos> scribenick: nikos
<heycam> ACTION: stakagi to specify how the zoom media query would work with HTML as well
<trackbot> Created ACTION-3438 - Specify how the zoom media query would work with HTML as well [on Satoru Takagi - due 2013-02-13].
heycam: So
... We have TTWF on Friday night and I wanted to get Shepherd running so we could commit tests
... I got instructions from Peter Linss, but it requires some admin changes to the server
... I asked JWatt if he could do that but he's unsure if we should continue using his machine
... it might be better to move it to somewhere else (perhaps Cam's) host
... I will co-ordinate to do that but it means the repository won't be ready Friday
... but we can store tests on a shared drive or dropbox for TTWF
Cyril: we didn't use a repository for Paris because it takes too long for the attendees to setup
... in Paris there were no topics on SVG, so no SVG test were created
... the topics were CSS, HTML, mobile, indexDB
... is it planned to have one in Sydney?
heycam: yes, the web page lists SVG and some CSS
krit: CSS filters and transforms
heycam: as part of the moving process I will reorganise the repository so we can add new specs there
<heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jan/0057.html
heycam: in the spec atm we have getStrokeBbox which includes the fill and the stroke as separate methods
... firstly I'm not sure about the name as the spec seems to include markers
... and it might be useful if you can control exactly which of fill, stroke, and marker are included
krit: you pass a dictionary, would it be possible to pass a set of keywords?
ed: that would be good, dictionary makes it verbose
... I'm not sure if the enum values we had are better
heycam: the alternative is possibly an array of strings?
... or variatic, take string ...
... might be a bit hacky
cabanier: what do JS people like?
heycam: this method is pretty common
... you could do fill:expression which is evaluated to true or false
krit: it must be backwards compatible so no option would mean just fill
heycam: dictionaries are always optional
... maybe it doesn't make sense to control whether the fill contributes?
... is it a useful feature?
krit: if it's not useful, why are libraries doing it?
... you can get the bounding box and you can get the stroke bounding box
... stroke bounding box does not include the bounding box
<dmitry> Suggestion of bounding box to include transformation inside. this is very useful for JS people
heycam: I think we discussed a get transformed bounding box function
... so it would be the bounding box of the transformed shape, rather than the transformed bounding box
<dmitry> Yes, of course
krit: we have a discussion tomorrow, there are problems with transforms
heycam: we could have an additional argument, which is the element whose co-ordinate space the returned bounding box is in
... I may have written up a proposal on the wiki about this
cabanier: how does that work with non-scaling stroke?
<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/getBBoxOf
krit: There shouldn't be a difficulty working out the bounding box
cabanier: that would be the bounding box of there rendered object
krit: that's what you want
cabanier: can you create a detached SVG element and ask for it's bbox?
krit: you will get an empty rect
heycam: that may not be specced
ed: so you couldn't ask for a bounding box of something in a def?
cabanier: or display:none
heycam: that doesn't work
ed: if we don't have it we calculate it, it's not that expensive
heycam: so getting back to the design of the get bbox method
... do people think it makes sense to add the functionality to getBBox rather than have a new method?
cabanier: I think people like dictionaries
ed: what about for multiple stroking, do we want to say which are included?
heycam: you could always add a new dictionary member which specifies which
birtles: so the default is fill:true and everything else false?
heycam: the way the optional dictionaries are done in WebIDL is that you can assume they have been filled in as an empty dictionary. So we would say the default of fill is true and if you wanted to override it you would have to say fill:false
... so it would have the opposite behaviour of the other arguments
birtles: it's not unreasonable to have authors say fill:false stroke:true if that's what they want
... with dashing that will give a different bounding box to fill:true stroke:true
heycam: do we want the dashes taken into account? that's difficult
ed: it's cheaper to approximate the stroke
heycam: that's what we do internally
cabanier: cabanier: do you ignore miters-limit value?
heycam: not sure
krit: so if I set miter-limit to 1000 will that result in poor performance because of massive bounding boxes?
heycam: if you are only interested in approximating the stroke, authors can do it themselves
ed: I'm wondering how neccessary it is that it is exact
... could provide an option to specify accuracy
cabanier: accuracy is affected by whether you use the shape of the marker or the marker bounding box to calculate the overall bounding box
... it's not a tight bounding box if you use the marker's bounding box
... so should we have an option to select tight or not?
heycam: I would assume people are only interested in the tight version
krit: if we don't require the exact tight bounding box the result may be different across bounding boxes
ed: it probably doesn't matter too much
krit: will we have the tight property or will we always assume it's tight?
... should we add a new attribute to the dictionary?
birtles: I think for when you don't want tight - for performance reasons you will probably do the calculations yourself
cabanier: it seems slower to do it yourself
birtles: but with games and things you will probably know enough information that you can approximate well enough
... I have done that myself
... what I'm saying is that I have a hunch that the non tight bounding box may not be necessary and we should look at the use cases to see if they are valid before adding it
cabanier: it seems like something that would be easy to implement
birtles: but it complicates the api and you need to test, etc
cabanier: the default should be tight
ed: is it possible to get the tight bbox from all the graphics libraries?
krit: core graphics has some bugs with that
... I wouldn't assume it will be exactly the same from all graphics libraries
... but should be within a tolerance
... will never be smaller - that would be bad
ed: that would mean that you would have to involve the rendering library to get the area
birtles: I wonder what the use cases are for getting the bbox that include stroke but not markers?
krit: assuming it's not expensive for browsers, you might as well let people specify what they want
birtles: I think we should do the minimum that is useful and add more functionality later
... it makes it easier to maintain in future
ed: if you don't want the markers included in the bounding box ask for the bbox without them applied
heycam: do people still want a fuzzy bounding box?
birtles: I think generally the author can calculate that separately if performance is important
ed: Is it useful to have the full repaint bbox that includes filters and everything?
... I think I agree that the tight bounding box is the most useful
... for setting the viewbox for example
heycam: I would prefer to have tight for now and extend later if required
... it makes sense for the default to be tight
ed: tight would mean dashes are taken into account?
heycam: yes
... that is a a question I would like answered
... I can think of a stroke area where the dashing happens inside and that whole area is included in the bbox
ed: I think I would take dashes into account if I was asking for the tight bbox
... which might be harder
heycam: dash capping, etc, included makes sense. It might be a bit difficult to compute.
birtles: I also raised the question - when would you ever want the bbox with the stroke but not the markers?
... what are the use cases for that?
heycam: not sure. But I can imagine cases where you have a fill with the stroke around it and the markers are decorative so not really part of the shape in the context
... if we had the dictionary of options, and we ignore markers at the moment. Stroke would imply markers?
birtles: from a feature point of view, if we don't want a fuzzy bbox and we don't differentiate between stroke and markers then it would suggest that from an interface point of view it might be sufficient to have getBBox and getStrokeBBox as separate functions
nikos: that's less flexible later
heycam: I like the idea of using getBBox
... my preference is one function, tight, markers included
... we could include the co-ordinate system in the dictionary or as a separate argument
... when I say markers included, I mean controllable
... does anyone strongly prefer the other option?
all: no
RESOLUTION: We will add dictionary arguments for controlling inclusion of fill, stroke, and markers to getBBox(). The tight bounding box will be returned and there will be a method to control the co-ordinate system for the bounding box.
<scribe> ACTION: cameron to add dictionary arguments for controlling inclusion of fill, stroke, and markers to getBBox(). The tight bounding box will be returned and there will be a method to control the co-ordinate system for the bounding box.
<trackbot> Created ACTION-3439 - Add dictionary arguments for controlling inclusion of fill, stroke, and markers to getBBox(). The tight bounding box will be returned and there will be a method to control the co-ordinate system for the bounding box. [on Cameron McCormack - due 2013-02-13].
<heycam> trackbot, close ACTION-3340
<trackbot> Closed ACTION-3340 Add support for auto-sized images to SVG 2.
<dino> i guess no one is there.
<dino> ?
<heycam> dino, we've got the afternoon off
<heycam> trackbot, close ACTION-3414
<trackbot> Closed ACTION-3414 Add length shortcuts to SVG DOM.