Education/Projects/ProcessingForTheWeb/Performance

I have been looking at old test-cases for Canvas bugs which I discovered and submitted info on: such as Global Alpha, ArcTo, etc. Things seem to have been fixed, and it is great to witness Mozilla developers having moved things forward over time.

There are other bugs/performance issues and features which need addressing. The lists that follow will have test cases added shortly and I will be trying to link these to old bugzilla reports so we can get some outstanding threads closed down.

Performance Issues:

P100) Canvas Stalling - Canvas stalls with mouse movement, hardware interupts, CPU spikes etc and appears to stall at regular intervals when idle. GC suggested as likely cause. This behavior does not seem to be present in Safari or Chrome.

Test Case:
http://hyper-metrix.com/git/canvas-lab/performance/stall-sensor.html
Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=504640
https://bugzilla.mozilla.org/show_bug.cgi?id=482204
https://bugzilla.mozilla.org/show_bug.cgi?id=504640

P200) Slow Getting & Setting of Pixel Array - Currently pixels are being passed to a JS array. Some kind of abstraction is needed to act as an API to the JS developer, that while acting like an array. is really running at machine level.

Test Case: to follow
Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=499201

P300) Drop Frames - Firefox does not appear to have any mechanism by which to drop frames whereas Chrome most certainly does. It is possible that some of the perceived speed in Chrome's Canvas implementation is due to it's ability to drop frames that could not render in time. Ideally this kind of behavior should be switchable as it would not be desired for an application requiring the timed capture of frames for post-production, whereas it would be very desirable for games and interactive UI elements.

Example: http://hyper-metrix.com/processing-js/docs/?page=Drop%20Frames%20and%20For%20Loops%20-%20Chrome%20vs%20FireFox

Bugs:

The Canvas bugs I found earlier in the year have already been delt with by 3.5. Go Bugzilla!

Feature Requests:

F100) SVG Tiny 1.2 XML File to Canvas Pixel Array

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.

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.

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.

If someone could explain the problem in layman's terms, I will happily strike it from the list.

Existing Canvas ToDataURL Method: https://developer.mozilla.org/En/Code_snippets/Canvas http://www.nihilogic.dk/labs/canvas2image/

F200) Stroke Dash Array

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.

The closer we can bring the Canvas-API-methods to SVG-Tiny-path-methods... 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.

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.

W3C SVG Spec: http://www.w3.org/TR/SVG/painting.html#StrokeProperties
JS Stroke Dash Implementation: http://canvex.lazyilluminati.com/misc/dash.html
WHATWG Discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011224.html