IRC log of svg on 2014-10-31

Timestamps are in UTC.

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