Efficient SVG
CC Attribution - NoDerivatives 2.0 UK: England & Wales:
You are free to use, copy, distribute and transmit the work or content in unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Russell, Robert
As more developers have adopted SVG, questions have shifted from suitability as a format to more subtle questions about the best way to build with SVG in applications where it shines. Best practices are evolving for building applications, compatibility across implementations in different user agents, and for integrating SVG components as moving parts in larger HTML5 applications. The time has come to dive more deeply into efficient SVG applications. Google has been a part of building the current generation of broadly-adopted SVG applications. Google Maps and Google Docs rely on SVG for interactivity and a robust document format. Google contributions to WebKit are helping to build one of the best open source implementations for rendering SVG. However, it is the community of developers, like the SVG Open community who are building the next generation of domain-specific tools using SVG and the rest of the open web stack. Rob will compare real and perceived performant SVG coding practices, helping along the conversation around best practices for coding with dynamic SVG.
 So, I just want to say, my name is Rob Russell, I'm an engineer at Google and today I'm going to talk to you about efficient SPG. Hopefully, go through some coding practices that are beneficial and go along kind of the same page, get in the discussion about how, you know, the SPG is the best way to do this is to get in the discussion about how to make efficient SPG and see where we go. So, when I say efficient SPG, what is efficient? So efficient generally, I can vote maximum productivity, minimum least, minimum unnecessary, that sort of thing. Now, in the case of SPG, I'm willing in many cases to trade resources like memory or time up front in order to get better execution speed later on in the application when you need it. Obviously, memory efficiency matters too, but speed seems to be a concern with SPG applications, which are applications. So, that's what I'm going to focus on today. And when it comes to SPG, obviously, there's one of the one way to draw things, there's one of the one way to get a specific engine on the screen. You can use a raptor path or whatever else you need to use to build your graphics. And there can be different differences across platforms and as you know, choices to make. And so, my interest is in the speed theory application, and I'll look at the speed of one browser versus other browsers, which I think is pretty shiny for me in a way. The microform is working on this, which Microsoft and Google are both involved in, may help with measurements across browsers or the measurements of applications that are more accurate. But I'm not going to go into that. But we're focusing right now on how to get the best performance in your application or your image using practices that are available today in the release. So, there's two big buckets that I kind of threw things into here. Basically, I'm looking at building static images. So, images that are meant to be displayed in the same way as last year's in some web today, and also, or the alternative, being built in dynamic applications which are the ritual applications, in SCG. So, there are certain practical performance needs that you have when you build static images. And as SCG becomes more widely adopted for use in normal web pages, just your average web page, as Justin mentioned, in the special choice, Draven, we need to set user expectations appropriately, and users already have broad experience with brass images, and so there's an understanding of that. When you have a high-detail, high-resolution image, you're going to have a large brass image that you're going to have a certain expected file size, and that file size is going to have a very high development browser. Having a large brass image on the page, there's a certain expectation of what kind of performance you're going to have in the browser. It's going to be very useful. Now, we want, obviously, for users to build the access SCG images, the web pages have these basic new browsers, so it can help you to build a certain value, build on the user's understanding of what happens with brass images. And doing that, one concept that I find helpful is a modern resolution. This is something that I believe Wikipedia shows when you look at an SCG image and what Wikipedia. There's a resolution that the image is expected to be used as. There's a lower end and a higher end that you're expected to use that. This is the image. Now, of course, it's going to scale out infinitely, because it scales in infinitely, but typically when you use a piece of clipart, there's a size that it's going to show up on the screen. Keeping that notion in mind, I feel it helps to choose what details you can include, what details you can leave out, and leaving out details that are unnecessary over the range of resolutions that you expect is one way to get your image to display more readily to the lower processor, be personal to the render processor. It's also a choice that you have to choose in certain images. There's just too much detail where there could be infinite detail for display and fractal. There is an infinite detail there. You're going to talk to some point if you have a stack of images. So you're going to make that choice that's somewhat reasonable to make that part. So the other thing we don't want to do is use resources that are just before you can choose a benefit. So the user perceives a certain benefit from choosing what SCG on a page, and in many cases we can get SCG images to be much more space efficient than a register in the same place. So we want to make sure that we exercise a benefit and deliver the answer to any users who are creating these users. Now, of course, the difference with SCG being that we put this built with Markup and while we are not setting a certain markup with the velocity, those interest in precipitation is pretty much the same with the EXI. It's possible to reduce the size of the ID encoded. That sort of thing. But in general, right now what we have and what we have for the future is this Markup. And that's just fine. It can be demanding on processors to run a large system like this, but more characters simply have extra characters to save something. Doesn't necessarily have to be abandoned. It will impact your car's impact, for sure. For example, if you've got these two paths are same, you can represent the same path a lot with zeros. It feels like more precision, but once that's parsed and once it's in memory, then as far as the browser is concerned, those two paths are pretty much the same. Now, if you have to manipulate the state of Winstrip, of course, if you're manipulating large strings in JavaScript, then you're going to feel performance came there. So there's a difference in the distinction between what is something that you're manipulating or what is something that the attribute gets set and stays set. So getting into the source of the images that you're using and reusing is very important. So this is an example of some markup that I found in an image that I used from the browser. I wasn't going through looking for specific things, but I just kind of thought, okay, well, let's have a look through here so you can see how I can reduce my file size. And obviously, this is a bunch of repeated group elements which are empty. They serve no purpose to the end user. And in the application where this image is being used, where it's simply displaying the static image on the page, the browser has to parcel this text that it and has to create DOM elements for all these other groups. There's ways that the browser's going to make optimizations around this, but the fastest thing to do in there is to think it's just not even there. So if there's ways to find these sorts of empty elements, unused elements, unnecessary depths, elements that you know are going to be obscured on the page, it's good to get rid of those. And if you're doing something like offering pipeline, if you have a method of creating content that's automated, then check it kind of out with the reproducing and see what kinds of craft you're putting in there. Here's another example. Again, I just followed the language on the other video. Now this chart is scary in at least two ways. One's the data that it represents. See, it's got a scary thing. But if we look beyond what's on the page and we actually look at the text that's shown on the upper left there, the way that text is actually shown is a single path for every letter. Now there were times when there's not even support for text across browser platforms. Those days are hopefully behind us. So that's no longer, it's no longer necessary to turn your text into paths for display. There are other cases where something might say they need to have a very specific font and that font's not available or they need a very specific text effect, which they just don't want to be using the text effect that's available, and actually do for whatever reason. And so those those things are going to continue to happen. But when you just arbitrarily choose to explore those paths for standard fonts, they're already there for browser, you just heard yourself and you're keeping yourself out of search results for no good reason. It's accessible for no good reason. And in general, I would expect that, I'd expect that you're just playing text rendering and just going to be faster because that's not a text rendering code. Passly optimized for many of the paths that the browser matches as for G. So you can expect that in plain text rendering, you just go to play text rendering and you can expect that in the browser. One other note, if you have some experience or some success where you have to do this, make sure you include the description and the element of title and these provide alternatives. This is how practice is shown up in web pages for HTML when people use specific fonts and then they use a flash and an image will do off-screen text. So I expect those practices to emerge for special situations, but with standard, definitely stick to text. Another concern comes up when trying to draw a static image in SVG. We have the filters available in SVG on many platforms and they can produce some really beautiful light and effects. They can produce some really beautiful shadows and do some really nice things there. They're not always going to be slow. There are some in order to keep... With current communications, we do find some pretty performance impacts by trying to use filters. One of the things that I found is a filter resolution patch created to down the good read and reduce that slightly and you get a slight performance improvement for the speed of the lighting that's actually doing also specification of the rotation of the screws and the filters because of the type of processing they have to do. When specular lighting happens, before the lighting happens, you have to do generally have to do a blur and the Gaussian blur can be a significant portion of the time it takes to actually produce the render, the lighting effect. The example that could be copied up is the one from the specification and it uses a Gaussian blur and it simply feeds that back into the screen. If you have a specific case where you're trying to use lighting for a button or for a user interface element, then it's quite possible that the world technically gets used in 3D animation where you kind of make that blur into a specific image so you can create a raster if you know it's going to be the same size all the time, create a raster and then reuse that with a fader perhaps. I've done a couple of experiments on that, I'm very far from that. But for your specific use case you can try and cut the cost of that Gaussian blur. But today what actually happens if you want to do lighting across the web, most of the time what we want is just something smooth and shiny, we want something smooth and shiny, then just throw in a white gradient or a gradient that feeds to the alpha blend values. Gradients can be faster than real lighting, you'll get that smooth shiny effect which is what you may want and you can do all kinds of tricks. This is a very simple example and it's not hard to do with my hand, you just set it to the maximum of why. You can move around the target of the light or imagine a light. And the same thing works if you want to shadow up to the side and do a shadow gradient. This happens all the time, a lot of times you see people using this specific effect and you're doing it real because you don't think about how they did that or the notice that's lit and so it's well done. In this case I've used transition to colors, it's also possible to do a more reusable gradient if you do transition through opacity and moving that transition through opacity to a gradient that you can reuse on different color backgrounds or whatever. And partial transparencies get less expensive thanks to hyperacceleration and thanks to just better optimization in the browser. Transparency affects the habit across HTML and SVG. So moving from static images onto dynamic applications which is what we hear a lot about it which is one of the great strengths of SVG is being able to build very rich user interfaces. We have a lot of the same concerns, I can use a lot of the same optimizations that we use in static images. But we also have additional concerns with dynamic applications. We want to have smooth interactive performance. When the user is actually using the application, you might have a drag that happens, you want the smooth animations to be dragged, other times you should just sit inside and not do anything. You want similar behavior across different platforms on different random engines. You want your application to be accessible to all users. And one of the key here is that we want to be sure that we don't for the performance of other applications in the same browser. This is an important point to hit on because it's easy to do, sorry, I was going to say easy to do but easy is not sure. We can do demonstrations where we show high speed animation, high frame rates, we can do some really cool stuff. When we're doing demonstrations, we're doing demos, a lot of times we're not so concerned about CPU utilization, we're not so concerned about whether you can run something else at the same time as this and we're not concerned about the feedback we're going to create. So as long as it works, we're going to be doing demonstrations. Now, when you have multiple applications running and you're trying to build an application that the user doesn't think of all the time, it's just something that once a while you go to this application, you can run something later on in a couple of days and come back to it. You want to be sure that you're not running, for example, running an animation where it doesn't get too long. You want to be sure that your resources are available and you need them and freely don't. So in order to achieve this, we need to measure performance. So, measuring performance is both easier and harder now than it ever has been before. It's harder because of the optimization that are having browsers to make some light effects in animations and really impressive means and really impressively complex documents, but it also gets easier because of fantastic tools like the pictures I have here are from Firebug and from Web Inspector, but there's also great tools like Drive and Fly and in the Explorer has some great developers that have them. So use the tools in browsers that you're working on, whichever platform you're on, definitely learn how to profile. And these tools are great for ad hoc, very quick tests. If you see something funny happening, for example, in Web Inspector, you can simply open up Web Inspector, click on the record button and it will, in this case, it's showing that it's recorded how long a certain step state you can have or see what's going on there. And you can find hotspots in the application very quickly simply by repeating those actions and watching what happens. Now that's not a very rigorous test. This is for ad hoc, quick tests, and finding places that are worth investigating. And for this, I kind of built up a little speed measurement harness which was inspired by something that John's presented a previous test with GeoOpen. My method is very simple because it run the application many times in a test harness and then count how long it takes and divide by the number of times it takes to do it. So I have to do average execution times. So say you've got a rendering that happens and every time you're running load, you call it tick method and then at the end of the time, you divide up time. But the way you do it, you put that back to Web Circle, run it with the channel and it's pretty straightforward. The one thing, the one warning about running the test harness of that is if you want to have it tender, then there might be things that are happening on the screen that aren't what you want. So it's something that needs refinement and hopefully over time we'll get better at that. One of the things I came across though is no surprise, there is a cost to a live DOM. This is a thing we've heard before. The live collections in the DOM make for some very easy to access scripting elements so you can kind of just touch something and see your reaction anyway. But that comes at a very high cost. There's recalculations that happen sometimes, maybe unexpected. And there's a few approaches that have evolved for this with time with HTML, web applications, where you can cache, if you have a live collection, then you can cache the length which just means you will get the length of the collection, sort off the JavaScript variable and then you can just do that later as long as you're not modifying the DOM and it does live attractions. There's also query-selectrol method. query-selectrol method seems relatively recent that it's coming to kind of the zone where it's acceptable to use because it's implemented in a wide-ended browser, and query-selectrol returns a collection which is not live. So that's very important because it means that when you use that collection, then you're not going to incur any costs back in DOM now in that way. That does also mean that you have to manually push stuff back in DOM when you're ready. It's also good to note that there's certain SVG methods that are specifically called out in specification. They return a node list, but that node list is specifically called out to be not live. So a couple of examples, get an enclosure list, get an intersection list, and I think there's a couple of others as well. So it's good to know whether the question you're working with is live or not. So you have to don't touch the DOM. It's expensive. If you've got something that's UI intense, then you want to make sure that you understand when you're doing that. Interaction. Pre-count the value as much as you can and use the spend-redraw to get it to a little bit more here. So this is an example that gets you back a, get on a class name, gets you back a live collection. This example here simply indexes it to it, but not just indexing it into it, it causes pain, but when you actually go back and modify the reference to get from gala into class name. So it can be a tricky issue to understand. Do it once it's okay, but using that collection over and over in some type of, it's going to cause you pain. Now that said, don't optimize too or really don't, you know, don't sweat up with this too much. Go up, build something and then find out what happens. So when you do touch the DOM, because I said don't touch the DOM, I'm sure you're going to notice it. Always, always make sure that you create your element, set the attributes on it, then attach it to the DOM. Never do this the second after that. Second, if you can't see what the difference is, in the second case, what's happened is the DOM, the element's already cracked, it's all in some default values, and now it's being adjusted. So do it before you do. Document fragment can help with this. This is something I'm surprised at how little usage it gets. It's simple to create a document fragment and you can treat it just like if you create a group element. You attach things to it, you build up this collection, and then you attach it to the DOM. This is the kind of thing, you can see kind of the verbosity that you complain about in DOM functions, but a lot of times this can be abstract away into some function that you cause. You don't necessarily have to see this all the time. But building up this fragment like this, and then attaching it to the DOM, you're working with the APIs that we have. You're working with the APIs that are built for this. The other one I might add here was a suspend redraw. And suspend redraw, if you're not familiar with it, is a function which will hold off on rendering the document. So you still incur the cost of manipulating the DOM, but you won't be rendering the output during that time. So for example, you could call suspend redraw to wait 100 milliseconds, do a bunch of manipulation, then you call unspend redraw with the handle that you got earlier, and you're paid to be updated all at once, and get all that running just once. Now, sometimes you're making an optimization like that, and you don't know exactly why there was actually no effect to it. You kind of dig into like, what's going on here? Well, with open source rendering engines, sometimes you could do some detailed analysis, getting the code. Figure out just exactly what's happening there. This is a line code from WebKit. So today, definitely WebKit, but if you are talking about 1.275, it's now a doob of a 10 world heap. But I mean, it's open source code, so we can see the server thing. And hopefully, one day that will be in there. Maybe somebody here is inspired, and Google makes changes. But still, make a call to unspend redraw. The function is there. The reason is there is so that you can call it, so that you can use the same code across the platform. So it's definitely a private state. Now, when you do call unspend redraw, you update your page. When you're updating your page, the reason you're going to consume an animation. And whenever we're talking about animation in SVG, we always look at the smile animation versus job search animation. It always has to be phrased that way. It has to be phrased as smile animation versus job search animation. And of course, the smile animation could potentially allow the poor browser to predict the future of it. What I mean here is, hypothetically, I don't know if this is a background development, but it's anywhere right now. You could make a calculation based on the values that are assigned to an anime element. So that when a user switches away from your application and switches back, no matter if you don't have to do that animation in the background, you can potentially predict the value based on calculation. So you have kind of a continuous animation around the screen, calculated animation. Now, smile animation is often held up as a good example of deferent workup, and it's great that it's declared, but nothing's true. Just because it's marked up doesn't mean it happens instantaneously, it involves happening instantaneously. The value calculation still has to happen, the rendering still has to happen, all the same work still has to happen as what happens for your job search animation. Except getting the DOM. You don't have to call the AK to do the modification, but the tradeoff is you've got in the end of the film. So it's interesting though, looking at, actually let me get back to that in one second, because there is one other thing I want to mention in Rosilla, it's at least looking at optimizations that can be made for job search based animation. The Get Smalls Request and Mainframe method, it's meant to hold off on animation again. So there's an experiment happening there, and it's good to know. So maybe we'll see improved performance in job search animation as well. But the way I like to look at it myself is at smile animation and job search animation, because like you said, smile is part of the DOM, or it's part of the document, it's deferent workup, and we can do modifications to the DOM in job search animation. Because I can mention the document that you grabbed, the anime element, and this example here, which probably proves it's bad values, but basically we can, we can calculate the values that we're going to use for animation and make that animation happen. A lot of times with the block of smile animation, they look for long, long running continuous animation, which is fine. But it's also true that if you had a one second animation, whose positions you did not make at creation time, you could calculate those values whether the user performs an action, then assign those values to the anime element. And then the advantage of this would be that the animation that happens with all the elements of smile and optimizations are available for smile, and you don't have to figure out your animation time at tick that you would do with job search. So this is just kind of a hypothetical thing, it's just something to remember that if you are doing smile animation or job search animation, there are ways to make the tune, and it is possible. And there are also events that are fine for detecting whether the animation starts or stops, so you kind of interpret it much more than we've seen in the past. One of the minor ones that I wanted to hit on was transformations. When we do OEM, very often what we're animating is the transform. And so you have to have some specific transformations that you document that you can modify over time. But if you have a whole bunch of transformations, you have a whole bunch of elements, then there's always a way you can't bake in those values into the improved absolute coordinates, which would be easier to digest for the browser. So what I'm saying here, when I say bake in, what I'm saying is run through the calculation, and then run through the any absolute coordinates that will make something that's easier for the browser to understand or to quickly run out. This is something that's more useful if you're building something that has a toolchain. So if you have some toolchain and it has some SVG resources, then consider this as part of something you think about to improve some efficiency there. Some of the things you would look at, there's methods for getting values and specific units. You can get coordinate transforming tricks and you can get specific transform that's applied to OEM. So you could actually, in JavaScript, run through if you could open all the initial positions from the transform that you can have on a fly in no runtime, and then get back a path resource that you should be taking. Use that as your best feedback for your initial application. So there's one more concept that I wanted to get on here, and this is something that I've actually seen several times during the SVG Open this year. That's got a level of detail. Level of detail, I thought I would have to explain, but it sounds like everybody kind of already has a concept of this. There are, I come at it from the, my dinosaur's kind of, basically what I'm showing here is there's different 3D meshes that are shown here and in 3D animation, one of the techniques that's used is this level of detail concept where if you have an object that's close to you, you have a 3D mesh that has very many vertices in it. Now when the object is close to the camera, then all those vertices are needed and you need that high level of detail. When the object is far away, if you use the exact same mesh object, then you've got basically a whole bunch of vertices that are contributing nothing to the final image that's shown on the screen. So you have a whole lot of detail that's thrown away, a whole lot of data that you really don't need. So I did a little experiment using this level of detail. The concept, like I said, is using reduced complexity path for objects that are at a smaller scale, not actually far from the previous phase, but a smaller scale. And when that path comes, when that object is something that comes up a little bit closer, then you would, or whatever it goes, a larger scale. Then you would use a higher complexity path to get the details that you need. But kind of a small example that I could show. So you kind of already want to talk to you about what's going to make sure it really won't work. So it's not a big deal, it's just kind of some things bouncing around. So this is a, I grabbed a complex, kind of complex map of Wikipedia. I have no idea if it's the file here or just, and I just wanted to animate it and see if it can kind of have a high-fives. But here it's fixed as a frame, maybe 23 milliseconds or something. It's just a decent handle. And the idea was, I got this image that takes a little while just to run around the screen. Now I want something that complex and I want to use it in animation, and we should definitely be able to do this in SVG. One thing to note here, it might look like the smaller ones are moving faster, that's because I didn't correct the velocity. So I'm making the velocity type of thing, but I've got some objects that look fixed, that are on. And you can't see it here while I'm going to be careful, but this would be the test of the technique. When it's a larger scale, I'm actually using a high-resolution path, and when it's a small scale, like it's a low-resolution path, this is something that was brought up a couple times in the demonstration. Specifically, the media queries sound like a great way to deal with this in other cases. And when I... I don't think that one is better. Now, when I start on this, I grab the image that's closest to what I grabbed, this is one down here, that 85 kilobytes. I'm using the file sizes to have a proxy for path complexity because in this file, there are two paths which dominate the size of the file. And you can see down the bottom, you've got this combinage path that has a lot of to-go-lunch-to-end, it's a lot of detail. And up here, there are 22 kilobytes. I remove the lack of to-go-lunch-to-ends, and there's a lot of curvy, uglyness. So, let me get back on this. Let's skip this thing. And basically what I did, I started out with an image from this initial work of media. I pulled out the things that were obviously not necessary inside, and the smalls that you get down to the 85 kilobytes after the voucher scouting and everything else. Then, basically what I did was I loaded up in inkspeak, select path, hit reduce path to find the simplified path, which will allow a couple of months, and once for each step here. So, there's a path for the L1B open, there's a path for the other contents on the global and I did that for each of them. And you can see there's a point, there's kind of initial returns. At first we get a step down by half the size, and then we step down maybe two-thirds the size, and then at the end there where it gets down is where we go to the long lines because you can't see because it's a long line. So, there's, depending on the scale range and the normal resolution of the images that you're using, you're going to have a different number of levels that you'll need. Now, there's many ways to apply this but I try to field them. One being just to visit the attributes of the path element, another would be if you set up the images as desks, then you can use the use element and you can swap out the href value. There's a third method but if you bear with me I'd like to look it up here really quick. See if I can double or double the value. See if I can test my network connection. Okay, I'm going to do that after I pop in a second. So, let's see. Insight search for the wordalpattersy because that's what I want. Let's see if there's the sg file. I was looking for, thank you Doug. And in case you missed it there, what I just did was search for sg files and Google then that works out. So, what Doug says here is that the cheapest is displaying none. So, into the levels of detail, make one way visible. And, yeah, so in my experience at a level of detail, I found that using multiple levels did provide a significant time saving to the different room. It did help a lot. The method that I used to switch paths didn't make that much of a difference but that could be because I hadn't hit an array one yet. And choosing the right scale to rate points in time to switch levels makes a huge difference in that specific test application. Now, so I think there's a lot to be said for the most part. But, yeah, so the themes I tried to have today, making your constants, anything that's constant, run it through the document, keep the same if you're using something that you're using often. Pre-calculate as much as you can to reduce startup time. So calculate stuff out, build up document fragments and attach them. Don't touch the dog. And measure the performance curve because this is quite a hot spot. Hopefully not just by watching the ECP meter but as development tools continue to improve then we'll find better ad-hoc looks for these pieces or build up frameworks. There are several things I didn't hit on today. Probably I didn't look at using XMLHTTP requests efficiently. I didn't look at network delays. These are critical points, but I think that it's roughly the same as it is for HGL documents. But in general that's the problem. And if I'm allowed to tell the web already, I should refer to using techniques. I did look into masking clipping which has significantly performance impacts and I wish I had more time to do it. And I didn't look too much into text display render but like I said I believe the text, the reduced text, text rendering facilities that are needed to the browser, needed to the platform as much as possible, then you probably know the best performance that just seems intuitively right. And then there's a kind of a learning theme now where people ask for ways to make SVT so I would like to see SVT become more efficient. The things that I'd like to see that aren't necessarily, aren't usually necessary to do the specifications so much as just further implementation of the specification as it is. Just keep refining things and optimizing. So, smile and recommendation and refinement, filter performance improvements. And the other one being the other one that I don't know if this is something that belongs to specification or something that belongs to the framework but if we had better ways to approach multiple representations of a single element, so high detail, low detail, one for scale 1 to 10, one for scale 10 to 100, that would be something that would be improved by the time. So with that I guess I'm going to wrap up and thank you for your time and I hope some of this helps and if there's any spots that aren't working, they're really wrong then feel free to call me on it. I tried to verify things if I could but it's obviously based on other research that's already out there. I hope to dig into it deeper over time and get to see how it should go. So, thanks for your time. So, I think we have some minutes left if there's any questions. Simplifying past data in maps has been known to cartographers as generalization and there's a very efficient, I mean you did it in Inkscape but Inkscape isn't very well suited to that. There's an online tool that's unfortunately in flash, it's called Map Shaper, it's done by the graphic designer from the New York Times and there you can load the standard shapefile data and have a slider where you can generalize and simplify past data from maps and that is very useful to speed up map display. I'm going to take note of that too, thanks. Illustrator also has a simplified path. Pardon? Illustrator. Illustrator as well. Illustrator has a simplified path that uses the same algorithm. But it's not about just simplifying past because in maps sometimes if you use Illustrator or Inkscape and you simplify then the borders don't align anymore. That's the problem and if you have a cartography's generalization tool then it's always the case that the borders after generalization still align. Right, there's a presentation about the problem of border alignment in geography data and that map data is something that I've had a lot of later on. I'm excited there may be other domain specific concerns for certain images and different algorithms that would make more sense. I wanted to say a great presentation. I think most of what you said actually applied to IE as well. A couple things. You mentioned something about pre-gap data in Transforce. It's quite true but so far we're skipping in line that the browser can apply to Transforce so that's why students can't change the game. At least in the internet exploration application you can use a lot of tricks to observe the interface. It's really, really fast. So it might sometimes give, you know, my connection with the app. Yeah, I think I might have come across it incorrectly there. I didn't mean to say that the application should perform a transform instead of having the browser to be used as much as possible. Rely on the code that's written in cc++ instead of trying to read it and reinvent it. What I was trying to point out there was that if you have a workflow whereby you have input documents in a scene and in order to optimize those next few documents you may have produced some other tool then your application will run through in a one-time fashion. So one time you run through all of the calculations before the transform is getting the bodies back and then feed that back into your system. So it's the same path back that you've been talking about as you're getting put into the next time. Yeah, there's no question that if you can make a head-to-head mission once it's done. In terms of the level of detail, I think there are places where within a spec it's currently, for example, with epic turbulence you can set a number of octaves, which is a controller over the amount of detail. There's a number of octaves increases, the amount of time the render increases. But there are other situations in which it might be nice for the user to be able to say, I only care about so much detail or to say good enough as an attribute value. There is a good enough attribute value. It's the level right here. There's a render and parameters attribute and there's an optimized speed value. So that would approach the good enough that you're looking for. I was going to mention that as well as things I didn't look into. I did actually try it really quickly. I just expect that given the maturity of the limitations, I assume that most browsers don't have multiple paths, as was expected in the end, whether it's specification or not. So it's possible that that could be something that browser vendors could look into as, if there's a divergence between dynamic applications and stack images, so it's not something that you want high quality. Like you said, in other cases, you have a good enough value. There are other things you can do for the good enough where you like to reduce filter resolution. You can reduce, for example, an Gaussian word number, standard deviation. That makes a huge difference in execution time, but if you reduce number, standard deviations, you're sacrificing quality. And not actually the quality in a little way, but sometimes it's in a very, very big, very noticeable way. In some cases where there's a lot of calculation going on, I think one could pre-calculate when the image becomes asymptotically similar to a previous incarnation. And that would be kind of cool. That would be kind of cool if we had to come down to the project. Interesting. I was just talking about the image that you had to build the code for the views. And something that I hadn't tried that I thought maybe you might have hit on was, was the performance of the views after you started animating, or the trade-off of cloning them into the DOM up front and taking that bit, because I would think that it might be a little patient to sit there and I think you would have to play with it myself. I did look. So the big thing that I noticed from the data was that the difference in choosing all this is in the detail was there. So I went down that path to investigate. I really do want to dig more into that, I haven't got a clue yet. One of the things that you can usually use is in terms of certain things you can't control. Let's see what you call that. So, yeah, I don't have a solid answer. It is definitely different across from the platform. I tried it, yeah, I got my demo, well, yeah, almost all my instructions were in the I9 test drive, and the rendering is quick, so there's a big difference. You know, the instruction was dominant, which is, I think, if they're expensive versus the leverage. Are your slides going to be available online so we can point to them? I hope so. It doesn't just happen, but actually, it's the things that box are alive, right? No, Rob, I'd just like to echo, can't put a great presentation. Well, I guess you got two comments. One on the last one about the hiding disability. I think what Doug hit on is probably a great way to go. If you're on both in line and you use the disability attribute, or the CSS attribute, you can do it with a change selector, you're not even touching the DOM. And we would pre-parse everything up, so it's actually loaded, it's taking memory, it's all loaded, but you're just going to flip its disability. I expected that to be a beautiful one. But you didn't see the big differences. Yeah, I kind of, I think it gets pretty solid tracks on, I would say, so I actually got a spotter. Well, it feels intuitively a great idea. It doesn't, that's the one reason I did it. And you're comment about Texas way, that's also super. It also helps your searchability and indexability, and it's great that you're indexing SVG. Another first Google thing. I was pretty excited with that, yeah. I guess one last comment, your workflow comment, I think, is great too, in many levels. You talked about cleaning up the cruft, flattening the transforms, if possible, if you're not changing those dynamically. And all that's great is when we look at stuff, the slowest SVG is the stuff that's directly exported or saved, whether it's Vizio, Illustrator, Rxcape, because all those products put in stuff so they can re-edit, re-open. Right, so there's always RAM tripping data in there, and there's always metadata in there. And it's a tough-out strike when you're asking about metadata, because you want that, like license integration, you want it to be in there, but then there is a lot of cruft that's just totally unnecessary, just hard to find. And grouping that was done when people created groups or layers in those applications, which actually are never used in the final rendering, you know, so flattening the whole idea, for a static image to be a huge win. Yeah, so Excape has a vacuum desk for that, and then Jeff, Jeff from the money version scour, I think, for, so you can actually save that scour SVG for Excape. I should have brought that up, and do that for us, because when you're using Excape, save that scour SVG, or if you use scour independently, you just go through that and you get a small amount of file. And then that, I think, you see kind of a script for coming up with lots of them, and that's available on the picture. And I want to emphasize one comment you made, which was, I'm not swearing too much, just to implement it. Yes. Yes. Absolutely. The productivity of the performance in the browser is kind of going steady down as the complexity is increasing. In particular, it's really hard to predict, in case you're going to explore exactly how much we're going to relay out, and re-display it for a given change. We have algorithms for those that are pretty complex, and predicting in advance what exactly will happen, and whether it's going to be optimal is difficult. So try it and see what happens. You have to experiment, and you have to test changes, and make sure you're testing the changes you think you're on. One of the things, like for an Explorer's case, and with Firefox on Windows, you've got to direct to the acceleration, and do as well. One of the things that I expect to not be bad, sort of, with SVG is methods that try to do things that have to, say, pull a texture back, or read from GPU. I know that's traditionally unexpected operation, but that would be something that's really unexpected for web developers. Yes. Okay, so we have to move on to the next topic, so let's thank our speaker again.
 So, I just want to say, my name is Rob Russell, I'm an engineer at Google and today I'm going  to talk to you about efficient SPG. Hopefully, go through some coding practices that are  beneficial and go along kind of the same page, get in the discussion about how, you know,  the SPG is the best way to do this is to get in the discussion about how to make efficient  SPG and see where we go. So, when I say efficient SPG, what is efficient? So efficient generally,  I can vote maximum productivity, minimum least, minimum unnecessary, that sort of thing. Now,  in the case of SPG, I'm willing in many cases to trade resources like memory or time up front  in order to get better execution speed later on in the application when you need it. Obviously,  memory efficiency matters too, but speed seems to be a concern with SPG applications, which  are applications. So, that's what I'm going to focus on today. And when it comes to SPG, obviously,  there's one of the one way to draw things, there's one of the one way to get a specific  engine on the screen. You can use a raptor path or whatever else you need to use to build  your graphics. And there can be different differences across platforms and as you know,  choices to make. And so, my interest is in the speed theory application, and I'll look at the speed  of one browser versus other browsers, which I think is pretty shiny for me in a way. The  microform is working on this, which Microsoft and Google are both involved in, may help with  measurements across browsers or the measurements of applications that are more accurate. But  I'm not going to go into that. But we're focusing right now on how to get the best performance  in your application or your image using practices that are available today in the release. So,  there's two big buckets that I kind of threw things into here. Basically, I'm looking at  building static images. So, images that are meant to be displayed in the same way as  last year's in some web today, and also, or the alternative, being built in dynamic  applications which are the ritual applications, in SCG. So, there are certain practical  performance needs that you have when you build static images. And as SCG becomes more widely  adopted for use in normal web pages, just your average web page, as Justin mentioned,  in the special choice, Draven, we need to set user expectations appropriately, and users  already have broad experience with brass images, and so there's an understanding of that.  When you have a high-detail, high-resolution image, you're going to have a large brass image  that you're going to have a certain expected file size, and that file size is going to  have a very high development browser. Having a large brass image on the page, there's  a certain expectation of what kind of performance you're going to have in the browser.  It's going to be very useful. Now, we want, obviously, for users to build the access  SCG images, the web pages have these basic new browsers, so it can help you to build  a certain value, build on the user's understanding of what happens with brass images.  And doing that, one concept that I find helpful is a modern resolution. This is something  that I believe Wikipedia shows when you look at an SCG image and what Wikipedia.  There's a resolution that the image is expected to be used as. There's a lower end and a  higher end that you're expected to use that. This is the image. Now, of course, it's going to  scale out infinitely, because it scales in infinitely, but typically when you use a  piece of clipart, there's a size that it's going to show up on the screen.  Keeping that notion in mind, I feel it helps to choose what details you can include,  what details you can leave out, and leaving out details that are unnecessary over the  range of resolutions that you expect is one way to get your image to display more readily  to the lower processor, be personal to the render processor. It's also a choice that you have to  choose in certain images. There's just too much detail where there could be  infinite detail for display and fractal. There is an infinite detail there. You're going to  talk to some point if you have a stack of images. So you're going to make that choice  that's somewhat reasonable to make that part. So the other thing we don't want to do is  use resources that are just before you can choose a benefit. So the user perceives a certain  benefit from choosing what SCG on a page, and in many cases we can get SCG images to be  much more space efficient than a register in the same place. So we want to make sure that  we exercise a benefit and deliver the answer to any users who are creating these users.  Now, of course, the difference with SCG being that we put this built with Markup and while  we are not setting a certain markup with the velocity, those interest in precipitation  is pretty much the same with the EXI. It's possible to reduce the size of the  ID encoded. That sort of thing. But in general, right now what we have and what we  have for the future is this Markup. And that's just fine. It can be demanding on  processors to run a large system like this, but more characters simply have  extra characters to save something. Doesn't necessarily have to be abandoned. It will  impact your car's impact, for sure. For example, if you've got these two paths are  same, you can represent the same path a lot with zeros. It feels like more precision,  but once that's parsed and once it's in memory, then as far as the browser is  concerned, those two paths are pretty much the same. Now, if you have to manipulate  the state of Winstrip, of course, if you're manipulating large strings in  JavaScript, then you're going to feel performance came there. So there's a  difference in the distinction between what is something that you're manipulating  or what is something that the attribute gets set and stays set. So getting into  the source of the images that you're using and reusing is very important. So this  is an example of some markup that I found in an image that I used from the  browser. I wasn't going through looking for specific things, but I just kind of  thought, okay, well, let's have a look through here so you can see how I can  reduce my file size. And obviously, this is a bunch of repeated group elements  which are empty. They serve no purpose to the end user. And in the application  where this image is being used, where it's simply displaying the static image on  the page, the browser has to parcel this text that it and has to create  DOM elements for all these other groups. There's ways that the browser's going to  make optimizations around this, but the fastest thing to do in there is to think  it's just not even there. So if there's ways to find these sorts of empty  elements, unused elements, unnecessary depths, elements that you know are going to  be obscured on the page, it's good to get rid of those. And if you're doing  something like offering pipeline, if you have a method of creating content that's  automated, then check it kind of out with the reproducing and see what kinds of  craft you're putting in there. Here's another example. Again, I just followed  the language on the other video. Now this chart is scary in at least two ways.  One's the data that it represents. See, it's got a scary thing. But if we look  beyond what's on the page and we actually look at the text that's shown on the  upper left there, the way that text is actually shown is a single path for  every letter. Now there were times when there's not even support for text across  browser platforms. Those days are hopefully behind us. So that's no longer,  it's no longer necessary to turn your text into paths for display. There are  other cases where something might say they need to have a very specific font  and that font's not available or they need a very specific text effect, which they  just don't want to be using the text effect that's available, and actually  do for whatever reason. And so those those things are going to continue to happen.  But when you just arbitrarily choose to explore those paths for standard fonts,  they're already there for browser, you just heard yourself and you're keeping  yourself out of search results for no good reason. It's accessible for no good reason.  And in general, I would expect that, I'd expect that you're just playing text  rendering and just going to be faster because that's not a text rendering code.  Passly optimized for many of the paths that the browser matches as for G.  So you can expect that in plain text rendering, you just go to play text rendering  and you can expect that in the browser. One other note, if you have some  experience or some success where you have to do this, make sure you include the  description and the element of title and these provide alternatives. This is how  practice is shown up in web pages for HTML when people use specific fonts and  then they use a flash and an image will do off-screen text. So I expect those  practices to emerge for special situations, but with standard, definitely stick to text.  Another concern comes up when trying to draw a static image in SVG. We have the  filters available in SVG on many platforms and they can produce some really  beautiful light and effects. They can produce some really beautiful shadows  and do some really nice things there. They're not always going to be slow.  There are some in order to keep... With current communications, we do find  some pretty performance impacts by trying to use filters. One of the things that I  found is a filter resolution patch created to down the good read and reduce that  slightly and you get a slight performance improvement for the speed of the lighting  that's actually doing also specification of the rotation of the screws and  the filters because of the type of processing they have to do.  When specular lighting happens, before the lighting happens, you have to do  generally have to do a blur and the Gaussian blur can be a significant portion  of the time it takes to actually produce the render, the lighting effect.  The example that could be copied up is the one from the specification and it  uses a Gaussian blur and it simply feeds that back into the screen.  If you have a specific case where you're trying to use lighting for a button  or for a user interface element, then it's quite possible that the world  technically gets used in 3D animation where you kind of make that blur  into a specific image so you can create a raster if you know it's going to be  the same size all the time, create a raster and then reuse that with a fader  perhaps. I've done a couple of experiments on that, I'm very far from that.  But for your specific use case you can try and cut the cost of that  Gaussian blur. But today what actually happens if you want to do  lighting across the web, most of the time what we want is just something  smooth and shiny, we want something smooth and shiny, then just throw in a white  gradient or a gradient that feeds to the alpha blend values.  Gradients can be faster than real lighting, you'll get that smooth shiny effect  which is what you may want and you can do all kinds of tricks.  This is a very simple example and it's not hard to do with my hand, you just  set it to the maximum of why. You can move around the target of the light  or imagine a light. And the same thing works if you want to shadow up to  the side and do a shadow gradient. This happens all the time, a lot of times  you see people using this specific effect and you're doing it real because  you don't think about how they did that or the notice that's lit and so it's  well done. In this case I've used transition to colors, it's also possible  to do a more reusable gradient if you do transition through opacity and moving  that transition through opacity to a gradient that you can reuse on different  color backgrounds or whatever. And partial transparencies get less expensive  thanks to hyperacceleration and thanks to just better optimization in the browser.  Transparency affects the habit across HTML and SVG.  So moving from static images onto dynamic applications which is what we hear a  lot about it which is one of the great strengths of SVG is being able to build  very rich user interfaces. We have a lot of the same concerns, I can use a lot  of the same optimizations that we use in static images. But we also have additional  concerns with dynamic applications. We want to have smooth interactive performance.  When the user is actually using the application, you might have a drag that  happens, you want the smooth animations to be dragged, other times you should just  sit inside and not do anything. You want similar behavior across different platforms on different  random engines. You want your application to be accessible to all users. And one of the  key here is that we want to be sure that we don't for the performance of other  applications in the same browser. This is an important point to hit on because it's  easy to do, sorry, I was going to say easy to do but easy is not sure. We can do  demonstrations where we show high speed animation, high frame rates, we can do some  really cool stuff. When we're doing demonstrations, we're doing demos, a lot of  times we're not so concerned about CPU utilization, we're not so concerned about  whether you can run something else at the same time as this and we're not concerned  about the feedback we're going to create. So as long as it works, we're going to be  doing demonstrations. Now, when you have multiple applications running and you're  trying to build an application that the user doesn't think of all the time, it's  just something that once a while you go to this application, you can run something  later on in a couple of days and come back to it. You want to be sure that you're  not running, for example, running an animation where it doesn't get too  long. You want to be sure that your resources are available and you need them  and freely don't. So in order to achieve this, we need to measure  performance. So, measuring performance is both easier and harder now than it  ever has been before. It's harder because of the optimization that are having  browsers to make some light effects in animations and really impressive means  and really impressively complex documents, but it also gets easier because of  fantastic tools like the pictures I have here are from Firebug and from Web  Inspector, but there's also great tools like Drive and Fly and in the  Explorer has some great developers that have them. So use the tools in  browsers that you're working on, whichever platform you're on, definitely  learn how to profile. And these tools are great for ad hoc, very quick tests.  If you see something funny happening, for example, in Web Inspector, you can  simply open up Web Inspector, click on the record button and it will, in this  case, it's showing that it's recorded how long a certain step state you can  have or see what's going on there. And you can find hotspots in the application  very quickly simply by repeating those actions and watching what happens.  Now that's not a very rigorous test. This is for ad hoc, quick tests, and  finding places that are worth investigating. And for this, I kind of  built up a little speed measurement harness which was inspired by something  that John's presented a previous test with GeoOpen. My method is very simple  because it run the application many times in a test harness and then count how  long it takes and divide by the number of times it takes to do it. So I  have to do average execution times. So say you've got a rendering that happens  and every time you're running load, you call it tick method and then at the  end of the time, you divide up time. But the way you do it, you put that back  to Web Circle, run it with the channel and it's pretty straightforward.  The one thing, the one warning about running the test harness of that is if  you want to have it tender, then there might be things that are happening on the  screen that aren't what you want. So it's something that needs refinement  and hopefully over time we'll get better at that. One of the things I came across  though is no surprise, there is a cost to a live DOM. This is a thing we've heard  before. The live collections in the DOM make for some very easy to access  scripting elements so you can kind of just touch something and see your reaction  anyway. But that comes at a very high cost. There's recalculations that happen  sometimes, maybe unexpected. And there's a few approaches that have evolved  for this with time with HTML, web applications, where you can cache, if you  have a live collection, then you can cache the length which just means you  will get the length of the collection, sort off the JavaScript variable and then  you can just do that later as long as you're not modifying the DOM and it  does live attractions. There's also query-selectrol method. query-selectrol  method seems relatively recent that it's coming to kind of the zone where it's  acceptable to use because it's implemented in a wide-ended browser, and query-selectrol  returns a collection which is not live. So that's very important because it  means that when you use that collection, then you're not going to incur any costs  back in DOM now in that way. That does also mean that you have to manually push  stuff back in DOM when you're ready. It's also good to note that there's certain  SVG methods that are specifically called out in specification. They return a  node list, but that node list is specifically called out to be not live.  So a couple of examples, get an enclosure list, get an intersection list, and I  think there's a couple of others as well. So it's good to know whether the  question you're working with is live or not. So you have to don't touch the DOM.  It's expensive. If you've got something that's UI intense, then you want to make  sure that you understand when you're doing that. Interaction. Pre-count the  value as much as you can and use the spend-redraw to get it to a little bit more  here. So this is an example that gets you back a, get on a class name, gets you  back a live collection. This example here simply indexes it to it, but not just  indexing it into it, it causes pain, but when you actually go back and modify the  reference to get from gala into class name. So it can be a tricky issue to  understand. Do it once it's okay, but using that collection over and over in  some type of, it's going to cause you pain. Now that said, don't optimize too  or really don't, you know, don't sweat up with this too much. Go up, build something  and then find out what happens. So when you do touch the DOM, because I said  don't touch the DOM, I'm sure you're going to notice it. Always, always make sure  that you create your element, set the attributes on it, then attach it to the  DOM. Never do this the second after that. Second, if you can't see what the  difference is, in the second case, what's happened is the DOM, the element's already  cracked, it's all in some default values, and now it's being adjusted. So do it  before you do. Document fragment can help with this. This is something I'm  surprised at how little usage it gets. It's simple to create a document fragment  and you can treat it just like if you create a group element. You attach things to it,  you build up this collection, and then you attach it to the DOM. This is the kind of  thing, you can see kind of the verbosity that you complain about in DOM functions,  but a lot of times this can be abstract away into some function that you  cause. You don't necessarily have to see this all the time. But building up this fragment like this,  and then attaching it to the DOM, you're working with the APIs that we have. You're working with the  APIs that are built for this. The other one I might add here was a suspend redraw.  And suspend redraw, if you're not familiar with it, is a function which will hold off on  rendering the document. So you still incur the cost of manipulating the DOM, but you  won't be rendering the output during that time. So for example, you could call suspend redraw  to wait 100 milliseconds, do a bunch of manipulation, then you call unspend redraw  with the handle that you got earlier, and you're paid to be updated all at once, and  get all that running just once. Now, sometimes you're making an optimization like that,  and you don't know exactly why there was actually no effect to it. You kind of dig into  like, what's going on here? Well, with open source rendering engines, sometimes you could do  some detailed analysis, getting the code. Figure out just exactly what's happening there.  This is a line code from WebKit. So today, definitely WebKit, but if you are talking about  1.275, it's now a doob of a 10 world heap. But I mean, it's open source code, so we can see  the server thing. And hopefully, one day that will be in there. Maybe somebody here is inspired,  and Google makes changes. But still, make a call to unspend redraw. The function is there.  The reason is there is so that you can call it, so that you can use the same code across  the platform. So it's definitely a private state. Now, when you do call unspend redraw,  you update your page. When you're updating your page, the reason you're going to consume  an animation. And whenever we're talking about animation in SVG, we always look at the smile  animation versus job search animation. It always has to be phrased that way. It has to be phrased  as smile animation versus job search animation. And of course, the smile animation could  potentially allow the poor browser to predict the future of it. What I mean here is, hypothetically,  I don't know if this is a background development, but it's anywhere right now. You could make  a calculation based on the values that are assigned to an anime element. So that when a user  switches away from your application and switches back, no matter if you don't have to do that  animation in the background, you can potentially predict the value based on calculation. So  you have kind of a continuous animation around the screen, calculated animation. Now, smile  animation is often held up as a good example of deferent workup, and it's great that it's  declared, but nothing's true. Just because it's marked up doesn't mean it happens  instantaneously, it involves happening instantaneously. The value calculation still has to  happen, the rendering still has to happen, all the same work still has to happen as what  happens for your job search animation. Except getting the DOM. You don't have to call the  AK to do the modification, but the tradeoff is you've got in the end of the film. So it's  interesting though, looking at, actually let me get back to that in one second, because there  is one other thing I want to mention in Rosilla, it's at least looking at optimizations that  can be made for job search based animation. The Get Smalls Request and Mainframe method,  it's meant to hold off on animation again. So there's an experiment happening there,  and it's good to know. So maybe we'll see improved performance in job search animation as well.  But the way I like to look at it myself is at smile animation and job search animation,  because like you said, smile is part of the DOM, or it's part of the document, it's deferent  workup, and we can do modifications to the DOM in job search animation. Because I can  mention the document that you grabbed, the anime element, and this example here, which  probably proves it's bad values, but basically we can, we can calculate the values that we're  going to use for animation and make that animation happen. A lot of times with the block of smile  animation, they look for long, long running continuous animation, which is fine. But it's  also true that if you had a one second animation, whose positions you did not make at creation  time, you could calculate those values whether the user performs an action, then assign those  values to the anime element. And then the advantage of this would be that the animation that happens  with all the elements of smile and optimizations are available for smile, and you don't have  to figure out your animation time at tick that you would do with job search. So this is just  kind of a hypothetical thing, it's just something to remember that if you are doing smile animation  or job search animation, there are ways to make the tune, and it is possible. And there  are also events that are fine for detecting whether the animation starts or stops, so you  kind of interpret it much more than we've seen in the past. One of the minor ones that  I wanted to hit on was transformations. When we do OEM, very often what we're animating  is the transform. And so you have to have some specific transformations that you document  that you can modify over time. But if you have a whole bunch of transformations, you have  a whole bunch of elements, then there's always a way you can't bake in those values into  the improved absolute coordinates, which would be easier to digest for the browser.  So what I'm saying here, when I say bake in, what I'm saying is run through the calculation,  and then run through the any absolute coordinates that will make something that's easier for  the browser to understand or to quickly run out. This is something that's more useful  if you're building something that has a toolchain. So if you have some toolchain and it has some  SVG resources, then consider this as part of something you think about to improve some  efficiency there. Some of the things you would look at, there's methods for getting values  and specific units. You can get coordinate transforming tricks and you can get specific  transform that's applied to OEM. So you could actually, in JavaScript, run through if you  could open all the initial positions from the transform that you can have on a fly in  no runtime, and then get back a path resource that you should be taking. Use that as your  best feedback for your initial application. So there's one more concept that I wanted  to get on here, and this is something that I've actually seen several times during the  SVG Open this year. That's got a level of detail. Level of detail, I thought I would have to  explain, but it sounds like everybody kind of already has a concept of this. There are,  I come at it from the, my dinosaur's kind of, basically what I'm showing here is there's  different 3D meshes that are shown here and in 3D animation, one of the techniques that's  used is this level of detail concept where if you have an object that's close to you,  you have a 3D mesh that has very many vertices in it. Now when the object is close to the  camera, then all those vertices are needed and you need that high level of detail. When  the object is far away, if you use the exact same mesh object, then you've got basically  a whole bunch of vertices that are contributing nothing to the final image that's shown on  the screen. So you have a whole lot of detail that's thrown away, a whole lot of data that  you really don't need. So I did a little experiment using this level of detail. The concept,  like I said, is using reduced complexity path for objects that are at a smaller scale,  not actually far from the previous phase, but a smaller scale. And when that path comes,  when that object is something that comes up a little bit closer, then you would, or whatever  it goes, a larger scale. Then you would use a higher complexity path to get the details  that you need. But kind of a small example that I could show. So you kind of already want  to talk to you about what's going to make sure it really won't work. So it's not a big deal,  it's just kind of some things bouncing around. So this is a, I grabbed a complex, kind of  complex map of Wikipedia. I have no idea if it's the file here or just, and I just wanted  to animate it and see if it can kind of have a high-fives. But here it's fixed as a frame,  maybe 23 milliseconds or something. It's just a decent handle. And the idea was, I got this  image that takes a little while just to run around the screen. Now I want something that  complex and I want to use it in animation, and we should definitely be able to do this  in SVG. One thing to note here, it might look like the smaller ones are moving faster,  that's because I didn't correct the velocity. So I'm making the velocity type of thing,  but I've got some objects that look fixed, that are on. And you can't see it here while  I'm going to be careful, but this would be the test of the technique. When it's a larger  scale, I'm actually using a high-resolution path, and when it's a small scale, like it's  a low-resolution path, this is something that was brought up a couple times in the demonstration.  Specifically, the media queries sound like a great way to deal with this in other cases.  And when I... I don't think that one is better.  Now, when I start on this, I grab the image that's closest to what I grabbed, this is  one down here, that 85 kilobytes. I'm using the file sizes to have a proxy for path complexity  because in this file, there are two paths which dominate the size of the file.  And you can see down the bottom, you've got this combinage path that has a lot of  to-go-lunch-to-end, it's a lot of detail. And up here, there are 22 kilobytes.  I remove the lack of to-go-lunch-to-ends, and there's a lot of curvy, uglyness.  So, let me get back on this. Let's skip this thing.  And basically what I did, I started out with an image from this initial work of media.  I pulled out the things that were obviously not necessary inside, and the smalls that you  get down to the 85 kilobytes after the voucher scouting and everything else.  Then, basically what I did was I loaded up in inkspeak, select path, hit reduce path to  find the simplified path, which will allow a couple of months, and once for each step  here. So, there's a path for the L1B open, there's a path for the other contents on the global  and I did that for each of them. And you can see there's a point, there's kind of  initial returns. At first we get a step down by half the size, and then we step down  maybe two-thirds the size, and then at the end there where it gets down is where we go  to the long lines because you can't see because it's a long line. So, there's, depending on  the scale range and the normal resolution of the images that you're using, you're going  to have a different number of levels that you'll need. Now, there's many ways to apply this  but I try to field them. One being just to visit the attributes of the path element,  another would be if you set up the images as desks, then you can use the use element  and you can swap out the href value. There's a third method but if you bear with me I'd  like to look it up here really quick. See if I can double or double the value. See if I  can test my network connection. Okay, I'm going to do that after I pop in a second. So, let's  see. Insight search for the wordalpattersy because that's what I want.  Let's see if there's the sg file. I was looking for, thank you Doug. And in case you missed  it there, what I just did was search for sg files and Google then that works out.  So, what Doug says here is that the cheapest is displaying none.  So, into the levels of detail, make one way visible. And, yeah, so in my experience at  a level of detail, I found that using multiple levels did provide a significant time saving  to the different room. It did help a lot. The method that I used to switch paths didn't  make that much of a difference but that could be because I hadn't hit an array one yet.  And choosing the right scale to rate points in time to switch levels makes a huge difference  in that specific test application. Now, so I think there's a lot to be said for the  most part. But, yeah, so the themes I tried to have today, making your constants, anything  that's constant, run it through the document, keep the same if you're using something that  you're using often. Pre-calculate as much as you can to reduce startup time. So calculate  stuff out, build up document fragments and attach them. Don't touch the dog. And measure  the performance curve because this is quite a hot spot. Hopefully not just by watching  the ECP meter but as development tools continue to improve then we'll find better  ad-hoc looks for these pieces or build up frameworks. There are several things I didn't  hit on today. Probably I didn't look at using XMLHTTP requests efficiently. I didn't  look at network delays. These are critical points, but I think that it's roughly the  same as it is for HGL documents. But in general that's the problem. And if I'm allowed to  tell the web already, I should refer to using techniques. I did look into masking clipping  which has significantly performance impacts and I wish I had more time to do it. And I  didn't look too much into text display render but like I said I believe the text, the reduced  text, text rendering facilities that are needed to the browser, needed to the platform as much  as possible, then you probably know the best performance that just seems intuitively right.  And then there's a kind of a learning theme now where people ask for ways to make SVT  so I would like to see SVT become more efficient. The things that I'd like to see that aren't  necessarily, aren't usually necessary to do the specifications so much as just further  implementation of the specification as it is. Just keep refining things and optimizing.  So, smile and recommendation and refinement, filter performance improvements. And the other  one being the other one that I don't know if this is something that belongs to specification  or something that belongs to the framework but if we had better ways to approach multiple  representations of a single element, so high detail, low detail, one for scale 1 to 10,  one for scale 10 to 100, that would be something that would be improved by the time.  So with that I guess I'm going to wrap up and thank you for your time and I hope some of this  helps and if there's any spots that aren't working, they're really wrong then feel free to call me  on it. I tried to verify things if I could but it's obviously based on other research  that's already out there. I hope to dig into it deeper over time and get to see how it should  go. So, thanks for your time.  So, I think we have some minutes left if there's any questions.  Simplifying past data in maps has been known to cartographers as generalization and there's  a very efficient, I mean you did it in Inkscape but Inkscape isn't very well suited to that.  There's an online tool that's unfortunately in flash, it's called Map Shaper, it's done by the  graphic designer from the New York Times and there you can load the standard shapefile data  and have a slider where you can generalize and simplify past data from maps and that is very useful  to speed up map display.  I'm going to take note of that too, thanks.  Illustrator also has a simplified path.  Pardon?  Illustrator.  Illustrator as well.  Illustrator has a simplified path that uses the same algorithm.  But it's not about just simplifying past because in maps sometimes if you use Illustrator  or Inkscape and you simplify then the borders don't align anymore.  That's the problem and if you have a cartography's generalization tool then it's always the case  that the borders after generalization still align.  Right, there's a presentation about the problem of border alignment in geography data and that  map data is something that I've had a lot of later on.  I'm excited there may be other domain specific concerns for certain images and different  algorithms that would make more sense.  I wanted to say a great presentation.  I think most of what you said actually applied to IE as well.  A couple things.  You mentioned something about pre-gap data in Transforce.  It's quite true but so far we're skipping in line that the browser can apply to Transforce  so that's why students can't change the game.  At least in the internet exploration application you can use a lot of tricks to observe the  interface.  It's really, really fast.  So it might sometimes give, you know, my connection with the app.  Yeah, I think I might have come across it incorrectly there.  I didn't mean to say that the application should perform a transform instead of having  the browser to be used as much as possible.  Rely on the code that's written in cc++ instead of trying to read it and reinvent it.  What I was trying to point out there was that if you have a workflow whereby you have input  documents in a scene and in order to optimize those next few documents you may have produced  some other tool then your application will run through in a one-time fashion.  So one time you run through all of the calculations before the transform is getting the bodies back  and then feed that back into your system.  So it's the same path back that you've been talking about as you're getting put into the next time.  Yeah, there's no question that if you can make a head-to-head mission once it's done.  In terms of the level of detail, I think there are places where within a spec it's currently,  for example, with epic turbulence you can set a number of octaves, which is a controller  over the amount of detail.  There's a number of octaves increases, the amount of time the render increases.  But there are other situations in which it might be nice for the user to be able to say,  I only care about so much detail or to say good enough as an attribute value.  There is a good enough attribute value.  It's the level right here.  There's a render and parameters attribute and there's an optimized speed value.  So that would approach the good enough that you're looking for.  I was going to mention that as well as things I didn't look into.  I did actually try it really quickly.  I just expect that given the maturity of the limitations, I assume that most browsers don't have multiple paths,  as was expected in the end, whether it's specification or not.  So it's possible that that could be something that browser vendors could look into as,  if there's a divergence between dynamic applications and stack images,  so it's not something that you want high quality.  Like you said, in other cases, you have a good enough value.  There are other things you can do for the good enough where you like to reduce filter resolution.  You can reduce, for example, an Gaussian word number, standard deviation.  That makes a huge difference in execution time, but if you reduce number,  standard deviations, you're sacrificing quality.  And not actually the quality in a little way, but sometimes it's in a very, very big, very noticeable way.  In some cases where there's a lot of calculation going on,  I think one could pre-calculate when the image becomes asymptotically similar to a previous incarnation.  And that would be kind of cool.  That would be kind of cool if we had to come down to the project.  Interesting.  I was just talking about the image that you had to build the code for the views.  And something that I hadn't tried that I thought maybe you might have hit on was,  was the performance of the views after you started animating,  or the trade-off of cloning them into the DOM up front and taking that bit,  because I would think that it might be a little patient to sit there and I think you would have to play with it myself.  I did look.  So the big thing that I noticed from the data was that the difference in choosing all this is in the detail was there.  So I went down that path to investigate.  I really do want to dig more into that, I haven't got a clue yet.  One of the things that you can usually use is in terms of certain things you can't control.  Let's see what you call that.  So, yeah, I don't have a solid answer.  It is definitely different across from the platform.  I tried it, yeah, I got my demo, well, yeah, almost all my instructions were in the I9 test drive,  and the rendering is quick, so there's a big difference.  You know, the instruction was dominant, which is, I think, if they're expensive versus the leverage.  Are your slides going to be available online so we can point to them?  I hope so.  It doesn't just happen, but actually, it's the things that box are alive, right?  No, Rob, I'd just like to echo, can't put a great presentation.  Well, I guess you got two comments.  One on the last one about the hiding disability.  I think what Doug hit on is probably a great way to go.  If you're on both in line and you use the disability attribute, or the CSS attribute,  you can do it with a change selector, you're not even touching the DOM.  And we would pre-parse everything up, so it's actually loaded, it's taking memory,  it's all loaded, but you're just going to flip its disability.  I expected that to be a beautiful one.  But you didn't see the big differences.  Yeah, I kind of, I think it gets pretty solid tracks on, I would say, so I actually got a spotter.  Well, it feels intuitively a great idea.  It doesn't, that's the one reason I did it.  And you're comment about Texas way, that's also super.  It also helps your searchability and indexability, and it's great that you're indexing SVG.  Another first Google thing.  I was pretty excited with that, yeah.  I guess one last comment, your workflow comment, I think, is great too, in many levels.  You talked about cleaning up the cruft, flattening the transforms,  if possible, if you're not changing those dynamically.  And all that's great is when we look at stuff, the slowest SVG is the stuff that's directly exported or saved,  whether it's Vizio, Illustrator, Rxcape, because all those products put in stuff so they can re-edit, re-open.  Right, so there's always RAM tripping data in there, and there's always metadata in there.  And it's a tough-out strike when you're asking about metadata, because you want that, like license integration,  you want it to be in there, but then there is a lot of cruft that's just totally unnecessary, just hard to find.  And grouping that was done when people created groups or layers in those applications,  which actually are never used in the final rendering, you know,  so flattening the whole idea, for a static image to be a huge win.  Yeah, so Excape has a vacuum desk for that, and then Jeff, Jeff from the money version scour,  I think, for, so you can actually save that scour SVG for Excape.  I should have brought that up, and do that for us, because when you're using Excape,  save that scour SVG, or if you use scour independently, you just go through that and you get a small amount of file.  And then that, I think, you see kind of a script for coming up with lots of them,  and that's available on the picture.  And I want to emphasize one comment you made, which was, I'm not swearing too much, just to implement it.  Yes.  Yes.  Absolutely. The productivity of the performance in the browser is kind of going steady down as the complexity is increasing.  In particular, it's really hard to predict, in case you're going to explore exactly how much we're going to relay out,  and re-display it for a given change.  We have algorithms for those that are pretty complex, and predicting in advance what exactly will happen,  and whether it's going to be optimal is difficult.  So try it and see what happens.  You have to experiment, and you have to test changes, and make sure you're testing the changes you think you're on.  One of the things, like for an Explorer's case, and with Firefox on Windows,  you've got to direct to the acceleration, and do as well.  One of the things that I expect to not be bad, sort of, with SVG is methods that try to do things that have to, say, pull a texture back,  or read from GPU.  I know that's traditionally unexpected operation,  but that would be something that's really unexpected for web developers.  Yes.  Okay, so we have to move on to the next topic, so let's thank our speaker again.
Efficient_SVG_2_0_59.png Efficient_SVG_2_60_179.png Efficient_SVG_2_180_779.png Efficient_SVG_2_780_1715.png Efficient_SVG_2_1716_3071.png Efficient_SVG_2_3072_8519.png Efficient_SVG_2_8520_8663.png Efficient_SVG_2_8664_8951.png Efficient_SVG_2_8952_11399.png Efficient_SVG_2_11400_14267.png Efficient_SVG_2_14268_15959.png Efficient_SVG_2_15960_17339.png Efficient_SVG_2_17340_22007.png Efficient_SVG_2_22008_25475.png Efficient_SVG_2_25476_27971.png Efficient_SVG_2_27972_28415.png Efficient_SVG_2_28416_30875.png Efficient_SVG_2_30876_32003.png Efficient_SVG_2_32004_32855.png Efficient_SVG_2_32856_36059.png Efficient_SVG_2_36060_40775.png Efficient_SVG_2_40776_42143.png Efficient_SVG_2_42144_42875.png Efficient_SVG_2_42876_43199.png Efficient_SVG_2_43200_43259.png Efficient_SVG_2_43260_43331.png Efficient_SVG_2_43332_43391.png Efficient_SVG_2_43392_43451.png Efficient_SVG_2_43452_43523.png Efficient_SVG_2_43524_43619.png Efficient_SVG_2_43620_43775.png Efficient_SVG_2_43776_43823.png Efficient_SVG_2_43824_43907.png Efficient_SVG_2_43908_43967.png Efficient_SVG_2_43968_44123.png Efficient_SVG_2_44124_44279.png Efficient_SVG_2_44280_44435.png Efficient_SVG_2_44436_44507.png Efficient_SVG_2_44508_44555.png Efficient_SVG_2_44556_44675.png Efficient_SVG_2_44676_44819.png Efficient_SVG_2_44820_44879.png Efficient_SVG_2_44880_44939.png Efficient_SVG_2_44940_45071.png Efficient_SVG_2_45072_45131.png Efficient_SVG_2_45132_45239.png Efficient_SVG_2_45240_46031.png Efficient_SVG_2_46032_47507.png Efficient_SVG_2_47508_48191.png Efficient_SVG_2_48192_48671.png Efficient_SVG_2_48672_48875.png Efficient_SVG_2_48876_48935.png Efficient_SVG_2_48936_49007.png Efficient_SVG_2_49008_49055.png Efficient_SVG_2_49056_49163.png Efficient_SVG_2_49164_49391.png Efficient_SVG_2_49392_50531.png Efficient_SVG_2_50532_52739.png Efficient_SVG_2_52740_54071.png Efficient_SVG_2_54072_55283.png Efficient_SVG_2_55284_56183.png Efficient_SVG_2_56184_57359.png Efficient_SVG_2_57360_58115.png Efficient_SVG_2_58116_58667.png Efficient_SVG_2_58668_61595.png Efficient_SVG_2_61596_62603.png Efficient_SVG_2_62604_63095.png Efficient_SVG_2_63096_66695.png Efficient_SVG_2_66696_71447.png Efficient_SVG_2_71448_72263.png Efficient_SVG_2_72264_72306.png