Education/Projects/ProcessingForTheWeb/Performance

From MozillaWiki
Jump to navigation Jump to search

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 very comforting 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

Bugs:


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