Education/Projects/ProcessingForTheWeb/Performance: Difference between revisions
mNo edit summary |
No edit summary |
||
| Line 16: | Line 16: | ||
== <br>'''Feature Requests:<br>''' == | == <br>'''Feature Requests:<br>''' == | ||
<br> | '''F100)''' '''SVG Tiny 1.2 XML File to Canvas Pixel Array''' | ||
<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 who suggested this could potentially be a major security issue. So it may be that we are forcedto 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 pixels array would be any less secure than passing graphics from the Canvas toDataURL. 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.<br></blockquote><blockquote>'''Existing Canvas ToDataURL Method: '''https://developer.mozilla.org/En/Code_snippets/Canvas http://www.nihilogic.dk/labs/canvas2image/<br></blockquote> | |||
Revision as of 07:50, 5 October 2009
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:
100) 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
200) 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 who suggested this could potentially be a major security issue. So it may be that we are forcedto 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 pixels array would be any less secure than passing graphics from the Canvas toDataURL. 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.
Existing Canvas ToDataURL Method: https://developer.mozilla.org/En/Code_snippets/Canvas http://www.nihilogic.dk/labs/canvas2image/