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

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.

Received on Wednesday, 6 February 2013 06:22:03 UTC