69
edits
Education/Projects/ProcessingForTheWeb/Performance: Difference between revisions
Education/Projects/ProcessingForTheWeb/Performance (view source)
Revision as of 18:13, 13 October 2009
, 13 October 2009no edit summary
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
<blockquote>This would be of great benefit the Processing.js project. Several people also requested this functionality at the SVGOpen conference 2009. Ideally the Canvas could natively rasterize a Tiny SVG directly to a pixel array. I spoke about this with Jonathan Watt ( a Mozillan working with the SVG implementation ), who suggested this could potentially be a major security issue. So it may be that we are forced to render SVGs to the Canvas with Javascript. Simple enough to acheive, but at a significant cost to performance.<br></blockquote><blockquote>I do not see how passing SVG graphics to a pixel array would be any less secure than Firefox's current method of passing graphics from the Canvas toDataURL. Not being a security expert, I can not tell if the request is inherantly flawed beyond my understanding or if I did not outline the desired behavior clearly to J.Watt.</blockquote><blockquote>To be clear... I am not suggesting that we rasterize an SVG that is already live in the DOM ( I could see why that could leak information ), I am requesting the ability to render a Tiny SVG from an XML file into a pixel array, without ever going near the DOM.<br></blockquote><blockquote>If someone could explain the problem in layman's terms, I will happily strike it from the list. <br></blockquote><blockquote>'''Existing Canvas ToDataURL Method: '''https://developer.mozilla.org/En/Code_snippets/Canvas http://www.nihilogic.dk/labs/canvas2image/<br></blockquote> | <blockquote>This would be of great benefit the Processing.js project. Several people also requested this functionality at the SVGOpen conference 2009. Ideally the Canvas could natively rasterize a Tiny SVG directly to a pixel array. I spoke about this with Jonathan Watt ( a Mozillan working with the SVG implementation ), who suggested this could potentially be a major security issue. So it may be that we are forced to render SVGs to the Canvas with Javascript. Simple enough to acheive, but at a significant cost to performance.<br></blockquote><blockquote>I do not see how passing SVG graphics to a pixel array would be any less secure than Firefox's current method of passing graphics from the Canvas toDataURL. Not being a security expert, I can not tell if the request is inherantly flawed beyond my understanding or if I did not outline the desired behavior clearly to J.Watt.</blockquote><blockquote>To be clear... I am not suggesting that we rasterize an SVG that is already live in the DOM ( I could see why that could leak information ), I am requesting the ability to render a Tiny SVG from an XML file into a pixel array, without ever going near the DOM.<br></blockquote><blockquote>If someone could explain the problem in layman's terms, I will happily strike it from the list. <br></blockquote><blockquote>'''Existing Canvas ToDataURL Method: '''https://developer.mozilla.org/En/Code_snippets/Canvas http://www.nihilogic.dk/labs/canvas2image/<br></blockquote> | ||
<br> '''F200)''' '''Stroke Dash Array''' | <br> '''F200)''' '''Stroke Dash Array''' | ||
<blockquote>Stroke dash array is a very useful tool for creating outlines that pop. Stroke dashes are an invaluable tool for rendering charts and graphs and can also be used for other Web 2.0 style effects such as radial bursts and | <blockquote>Stroke dash array is a very useful tool for creating outlines that pop. Stroke dashes are an invaluable tool for rendering charts and graphs and can also be used for other Web 2.0 style effects such as radial bursts and item selection bounds.</blockquote><blockquote>The closer we can bring the Canvas API methods to SVG Tiny path commands the better. While Flash is undesirable due to it's cost and lack of openness, it has a very well defined tool chain. This is currently missing in HTML5 open media technology and we cant expect the browser to become the standard development environment for future applications while the links between these open technologies remain so weak. We have learned from tools such as jQuery that while Javascript libraries are able to cover a multitude of sins, the work inevitably comes back to the vendor anyway.</blockquote><blockquote>With such great movement in SVG on the mobile web and in the browser, failiure to deliver compatible path methods in the Canvas API would be a considered a terrible oversight by immediate mode applications developers who wish to include SVG as part of their authoring tool-chain.</blockquote><blockquote>'''W3C SVG Spec:''' http://www.w3.org/TR/SVG/painting.html#StrokeProperties<br>'''JS Stroke Dash Implementation:''' http://canvex.lazyilluminati.com/misc/dash.html<br>'''WHATWG Discussion:''' http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011224.html<br> </blockquote> | ||
<br> | <br> | ||