Re: minutes, Pyrmonth, Sydney SVG F2F Day 3 (05/02/2013)

Attached is a HTML version of the minutes.

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

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.