00:39:56 <shans_> shans_ has joined #svg
00:48:25 <myakura> myakura has joined #svg
01:27:41 <stakagi> stakagi has joined #svg
01:37:00 <jun> jun has joined #svg
01:46:32 <ShaneM> ShaneM has joined #svg
01:54:49 <jun> jun has joined #svg
01:57:26 <birtles> ed: where are you guys?
01:57:43 <glenn> glenn has joined #svg
02:13:24 <birtles> cyril? cabanier? krit?
04:00:03 <glenn> glenn has joined #svg
04:22:55 <glenn_> glenn_ has joined #svg
05:14:05 <shans_> shans_ has joined #svg
05:30:20 <jcraig> jcraig has joined #svg
05:59:36 <jun> jun has joined #svg
06:06:50 <myakura> myakura has joined #svg
06:12:30 <jun> jun has joined #svg
07:10:42 <myakura> myakura has joined #svg
09:47:48 <jun> jun has joined #svg
10:24:18 <jun> jun has joined #svg
11:47:04 <myakura> myakura has joined #svg
16:07:30 <RRSAgent> RRSAgent has joined #svg
16:07:30 <RRSAgent> logging to http://www.w3.org/2014/10/31-svg-irc
16:07:38 <ed> RRSAgent, make logs public
16:07:57 <ed> meeting: SVG @ TPAC 2014 Day 2
16:08:01 <jun> jun has joined #svg
16:08:02 <ed> chair: ed
16:08:42 <ed> present: mark kilgard (nvidia), rik, dirk, shane, brian, jun, nikos, thomas, takagi, tav, chris, ed
16:08:57 <jcraig> jcraig has joined #svg
16:09:00 <ed> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda#Friday_09.00_-_10.30
16:09:50 <cabanier> scribenick: cabanier
16:10:09 <cabanier> topic: NVidia presentation
16:10:18 <cabanier> mark: thank you for having me here
16:10:30 <cabanier> ... these are various SVG files
16:10:45 <cabanier> ... we've been working on making vector graphics fast
16:10:52 <cabanier> ... for hires and tablets
16:11:02 <cabanier> ... this is one of the testbeds
16:11:15 <cabanier> ... we have and compare against cairo
16:11:44 <cabanier> ... we render all text from outlines and it is super fast
16:12:04 <cabanier> ... I work for NVidia and happen to be in town
16:12:19 <cabanier> ... SVG is different from how OpenGL is done
16:12:51 <cabanier> ... Used to think that 2D was iineffective but changed my mind
16:13:11 <cabanier> ... (overview of history of 2D vs 3D graphics)
16:13:58 <cabanier> ... most 3d works is moving 2d closer to 3d
16:14:17 <cabanier> ... so most work has not been that successful
16:14:31 <cabanier> ... MS has been making good progress
16:14:53 <cabanier> .... path rendering is one of the areas that has seen improvement
16:15:05 <cabanier> ... nv_path_rendering
16:15:37 <smailus> smailus has joined #svg
16:15:38 <shans_> shans_ has joined #svg
16:15:39 <BogdanBrinza> BogdanBrinza has joined #svg
16:15:53 <cabanier> chrisl: so you can keep the path so you don't have to tesselate or break beziers into lines
16:16:02 <cabanier> mark: yes.
16:16:15 <cabanier> ... we're making GPUs smart about bezier curves
16:17:00 <jun_> jun_ has joined #svg
16:17:01 <cabanier> ... there's another approach, paper is called: massively-parallel vector graphics
16:17:20 <Rossen_> Rossen_ has joined #svg
16:17:32 <cabanier> ... (overview of OpenGL pipeline)
16:17:52 <shans__> shans__ has joined #svg
16:18:01 <ChrisL> ChrisL has joined #svg
16:18:09 <cabanier> ... now there's a new path pipeline
16:18:42 <cabanier> ... once you have a path object, we stencil the path to do the winding
16:19:05 <cabanier> ... this is different on different on different GPUs
16:20:33 <cabanier> ... once stenciled, we put arbitrary geometry around it so it can be passed to a stencil buffer
16:21:19 <cabanier> ... one issues is that we flip between stenciling and drawing, which is what makes it really slow unless you make the driver aware of this
16:21:49 <cabanier> cabanier: how widely is this supported?
16:22:02 <cabanier> mark: all nvidia hardware from the last 6 years
16:22:25 <cabanier> ... other vendors are not as open
16:22:37 <cabanier> ... it's not important to their priorities
16:23:21 <cabanier> ... it's a bad situation for the 2d industrt. other vendors have the same capabilities but are wary to add them
16:24:29 <Tav> Tav has joined #svg
16:25:05 <cabanier> cabanier: so the stencil swapping is slow, can you just standardize that?
16:25:16 <cabanier> mark: ???
16:25:35 <cabanier> ... Illustrator is now GPU accelerated
16:25:50 <cabanier> ... and uses NVPath rendering
16:26:15 <cabanier> (overview how much faster it is)
16:28:29 <cabanier> ... overview: we can now stencil/cover very efficienty
16:28:46 <cabanier> ... 700,000 paths per second
16:29:46 <cabanier> ... from Maxwell on there are new GPU features specifically for web and path rendering
16:30:13 <cabanier> ... kepler for tegra was the first. Shield from NVidia, Nexus 9
16:30:57 <cabanier> (demos on the shield tablet)
16:33:32 <cabanier> ... Maxwell 2 has a complete feature set for accelerating 2D graphics
16:33:46 <cabanier> ... blends modes are all in
16:34:47 <cabanier> ... what is new in Maxwell 2: framebuffer configurations with mixed samples
16:35:18 <cabanier> ... 2d world doesn't care about depth buffer
16:35:47 <cabanier> ... so now you don't need that any more
16:36:10 <cabanier> ... with half the memory, you can do higher quality rendering
16:37:43 <cabanier> ... the stencil test, you run 16 stencil tests on a pixel
16:37:55 <cabanier> ... and you have 1 color
16:38:26 <cabanier> ... so you have far less memory and better quality
16:39:47 <cabanier> ... there are different configurations of coverage/stencil samples per pixel
16:40:46 <jcraig> jcraig has joined #svg
16:40:58 <cabanier> (overview that maxwell is faster and more memory efficient)
16:42:02 <cabanier> ... 1/4 to 1/6 of the memory of conventional multisampling
16:43:24 <cabanier> ... all the 2d extensions are on opengl.org
16:43:31 <cabanier> ChrisL: can we have the PDF slides
16:43:43 <cabanier> Mark: yes
16:44:10 <cabanier> ChrisL: what is NVidia's story on cheap GPUs?
16:44:38 <cabanier> Mark: there used to be an idea that there was a feature set difference between GPUs
16:45:06 <cabanier> ... we don't do that anymore. all features are in all versions of an architecture
16:45:49 <cabanier> ChrisL: you mention 4-6 years of compatibility will my laptop work?
16:46:05 <cabanier> Mark: you can look this up on the nvidia website
16:46:20 <cabanier> ... there are some demos there. We might need to update .exe
16:46:49 <cabanier> ... look for NVPRSDK
16:46:57 <ChrisLilley> ChrisLilley has joined #svg
16:47:00 <jun> jun has joined #svg
16:47:13 <cabanier> krit: do we still need to calculate bounding box, etc on the CPU?
16:47:21 <ChrisLilley> rrsagent, here
16:47:21 <RRSAgent> See http://www.w3.org/2014/10/31-svg-irc#T16-47-21
16:47:53 <cabanier> mark: you once have an nvpath, you can get tight bbox bak.
16:48:14 <cabanier> ... you can do path hit testing and path distance
16:48:36 <cabanier> ... for stroke we give you a conservative bbox
16:48:49 <cabanier> krit: you can support variable strokes?
16:48:56 <cabanier> mark: we don't do that for now
16:49:41 <cabanier> ... you can convert it to a path and fill it
16:49:55 <cabanier> krit: dash array?
16:50:02 <cabanier> mark: we support all that
16:50:22 <cabanier> krit: didn't mozilla try nvpath?
16:51:03 <cabanier> mark: very often the structure of a browser is very immediate, so you can't reuse objects
16:52:29 <jun_> jun_ has joined #svg
16:52:29 <cabanier> ... we're working on changing how they give data to the GPU
16:54:55 <cabanier> krit: how about meshes?
16:55:06 <cabanier> mark: yes, you can do those as well
16:55:36 <cabanier> krit: can you apply filters such as blur?
16:55:49 <cabanier> Mark: yes, during the cover stage
16:55:57 <cabanier> (shows an example)
16:59:01 <jun> jun has joined #svg
17:01:51 <cabanier> (talk about paths)
17:12:02 <jun> jun has joined #svg
17:13:18 <stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation
17:13:58 <cabanier> topic: Deeper investigation of the accuracy of the coordinates on rendering
17:15:51 <birtles> scribenick: birtles
17:15:55 <birtles> scribe: birtles
17:16:42 <birtles> stakagi: The coordinates accuracy of SVG is a fundamental theme for the maps. We need at least 8 digits of precision which is more than the range of a single floating point
17:17:06 <jun_> jun_ has joined #svg
17:17:07 <birtles> (discussing summary on above-linked wiki)
17:18:06 <birtles> stakagi: By providing a user coordinate system with an appropriate origin to each tile, the effective digits increases one digit in case of 10x10 tiling.
17:18:17 <birtles> stakagi: However, these tiles must be precisely pasted on the user coordinate system of the root which unifies them.
17:19:46 <birtles> (presents proposal outlined in wiki)
17:20:18 <birtles> stakagi: double precision computation should be performed for the calculation of CTM by nested transformation to suppress errors.
17:20:28 <birtles> stakagi: On the other hand, single precision is enough as CTM and the coordinate transformation computation. Therefore, single precision computation by GPU is possible.
17:20:46 <birtles> (demonstrates a test case for the precision of various browsers)
17:21:21 <birtles> stakagi: the slider changes the zoom ratio by changing the CTM (via the viewBox)
17:21:49 <birtles> stakagi: the setTileOffset field shifts the origin of the user space
17:22:40 <birtles> stakagi: This is the coordinate transformation operation equivalent to tiling of this proposal.
17:22:57 <birtles> stakagi: e.g. we can set it to 1000000000
17:23:17 <birtles> stakagi: then you see that when we zoom in, the origin vibrates
17:23:31 <birtles> stakagi: this demonstrates the error introduced
17:23:50 <birtles> stakagi: but I made a polyfill that computes the origin with double precision which suppresses the error
17:23:59 <birtles> krit: would double-precision solve the issue?
17:24:06 <birtles> ... it is up to the implementation to do that
17:24:21 <birtles> ... the SVG 1.1 says that it's up to the implementation to use double or not
17:24:29 <birtles> ... so it's up to the implementation to use double or not
17:24:55 <birtles> shepazu: do our hardware requirements from 2001 still make sense today or should be reconsider these today?
17:25:05 <birtles> ... does those assumptions still make sense?
17:25:19 <birtles> krit: as far as I know, double-precision can still be up to 4 times slower on mobile devices
17:25:53 <birtles> cabanier: DOMMatrix requires double
17:25:55 <birtles> ChrisLilley: stakagi was saying that we only need double for coordinating the CTM, not for rendering
17:26:00 <cabanier> spec: http://dev.w3.org/fxtf/geometry/#DOMMatrix
17:26:10 <birtles> ... I think that's useful to put in the spec
17:26:31 <birtles> ... I propose that we accept this
17:27:15 <birtles> ACTION: Takagi-san to spec that calculation of CTMs should use double precision
17:27:15 <trackbot> Error finding 'Takagi-san'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
17:27:29 <birtles> ACTION: stakagi to spec that calculation of CTMs should use double precision
17:27:29 <trackbot> Created ACTION-3674 - Spec that calculation of ctms should use double precision [on Satoru Takagi - due 2014-11-07].
17:27:31 <ChrisLilley> trackbot, status
17:27:33 <adenilson> adenilson has joined #svg
17:29:14 <birtles> topic: non-scaling dash patterns
17:29:38 <shepazu> shepazu has joined #svg
17:29:51 <ed> ed has changed the topic to: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda#Friday_09.00_-_10.30
17:32:02 <ed> -- 15min break --
17:49:32 <jun> jun has joined #svg
17:49:37 <smailus> smailus has joined #svg
17:49:47 <birtles> topic: New charter and priorities
17:50:05 <ed> http://www.w3.org/Graphics/SVG/2014/new-charter
17:50:14 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
17:50:20 <birtles> ed: this is the charter document
17:51:12 <Rossen_> Rossen_ has joined #svg
17:51:13 <birtles> Rossen: I had a quick question
17:51:18 <BogdanBrinza> BogdanBrinza has joined #svg
17:52:02 <Tav> https://www.w3.org/Graphics/SVG/WG/wiki/Topics
17:53:59 <birtles> topic: predictable SVG raster output
17:54:44 <birtles> BogdanBrinza: we came to this topic after discussing at MS with our Office teams etc. with regards to how they think of icons / graphic assets
17:54:53 <birtles> ... Office has about 10k icons with various resolutions
17:54:58 <birtles> ... Visual Studio have about 3k
17:55:15 <birtles> ... they have a team that just manage icons, create raster icons from vector icons etc.
17:55:22 <birtles> ... we want them to use SVG end-to-end
17:55:35 <birtles> ... we've asked, "what is stopping you from doing this today?"
17:55:46 <birtles> ... what they provided as a prioritized list of reasons
17:56:04 <birtles> ... one of the first things is that as a designer it's impossible to control raster output
17:56:21 <birtles> ... they are producing office publications, desktop publications etc.
17:56:32 <birtles> ... they have a range of resolutions
17:56:46 <birtles> ... they have an SVG icon master, suppose they set scale factor 0.8
17:56:54 <birtles> ... what they see as a result is not satisfactory
17:57:01 <birtles> ... they want to slightly modify it on a pixel level
17:57:03 <shepazu> http://www.w3.org/Talks/2014/schepers_invisible_visualization/responsive.svg
17:57:12 <birtles> ... it's fidelity at a pixel level
17:57:22 <birtles> ChrisLilley: so it's not a crisp in the way they might want
17:57:57 <birtles> smailus: we've seen the same problem at Boeing in that they don't downsample correctly
17:58:08 <birtles> ... when you stick a raster in SVG stuff starts to disappear
17:58:31 <birtles> shepazu: are you saying that the same image referenced in HTML and SVG are not downsampled well in SVG?
17:58:43 <birtles> smailus: in SVG it's not the same, and it's poor quality
17:58:49 <birtles> BogdanBrinza: I'll talk about that ltaer
17:58:53 <birtles> s/ltaer/later
17:59:51 <birtles> ... the second issue is lack of support in non-Web frameworks: XAML/Cocoa
18:00:13 <birtles> ... the alternative is to use fonts which is where they're heading
18:00:32 <birtles> ... the advantage is that they work well with native and Web applications
18:00:53 <birtles> ... more importantly, fonts have a well-established mechanism to control output through hinting
18:01:05 <birtles> ... all those problems are well understood in the font world
18:01:26 <birtles> ... from an SVG perspective, looking at fonts, they have major disadvantages such as not being animatable except for keyframe animations
18:01:38 <birtles> ... they cannot be combined with external resources for efficient workflows
18:01:48 <birtles> (keyframe animations meaning you need to put every frame in the font)
18:02:21 <birtles> Rossen_: one of the problems that icon designers face today is that even though fonts are inherently interoperable, they're not interoperable from the point of view of...
18:02:24 <birtles> ... for example, there's a variety of greyscale between different devices/platforms
18:02:34 <birtles> ... so people will have different hints for fonts for different platforms
18:02:42 <birtles> ... that blows up the set even more
18:02:55 <birtles> ... those hinting algorithms are proprietary to every platform
18:03:04 <birtles> BogdanBrinza: those hinting algorithms are proprietary to every platform
18:03:17 <birtles> ... but SVG should be cross-platform
18:03:30 <birtles> ... imagine three icons for Firefox, Chrome, and IE
18:03:58 <birtles> ... when we change the size we might just want to show the outline of the Firefox icon
18:04:07 <birtles> ... for the Chrome icon, the position of the different parts might be important
18:04:18 <birtles> ... so if we change the size the shapes might get out of line