SVG F2F Sydney 2013, Day 3

11 Feb 2013




<Cyril> scribe: Cyril

Performances to transition in zooming and panning


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)

non scaling objects

<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

improved bbox methods

<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.

Summary of Action Items

[NEW] 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.
[NEW] ACTION: ed to propose drawImage with SVGSVGElement to the public canvas mailing list
[NEW] ACTION: shane to investigate currentTranslate and currentScale on inner svg elements
[NEW] ACTION: shane to investigate the model for constrained transforms
[NEW] ACTION: stakagi to specify how the zoom media query would work with HTML as well
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012-09-20 20:19:01 $