[whatwg] Bug in defineProperty
Hello,
It seems there is a bug in function Object.defineProperty.
When property was defined with enumerable descriptor = false, I can
anyway get it in iterator if was defined prop with the same name in
object prototype.
Almost all browsers affected , except for Firefox. Maybe this happened
due to ambiguous definition?
Test
function test() {Object.defineProperty(this, a, {value : b,
writable : true,
enumerable : false,
configurable : true});
}
test.prototype.a = c
t = new test()
for(x in t) console.log([x, t[x]])
Results
IE9: a,b
Chrome: a,b
Safari: not tested
Opera: failed
Firefox: nothing - right job
-Evgeny
Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec
2010/11/15 Samuel Ytterbrink sam...@ytterbrink.nu: hmm... Can you explain the path-object more in detail. It sounds interesting... but why shouldn't i just create a function that takes a context and do the same path commands on it instead of having a context taking a path object? In case of 1000 path nodes , path object may save good portion of time due to caching mechanism. Inside IExplorer, path is serialized so that , I can drawing even complicated curves without a hung. And technical details: CanvasPath instance has all canvas path drawings methods , plus: append(path object) clone() push(segment) pop() Path segment is just an array, for ex. [moveTo, [0,0]]. In current version nodes are saved in _stack property, but i think CanvasPath should be special array, so that i can get n-th segment as path[n]. Related methods in canvas context: beginPath() - is created new path object inside context createPath() - creates and returns path obj instance appendPath() - appends to the current path clonePath() - clones and returns path obj Evgeny
Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec
On Sat, 13 Nov 2010 23:20:30 -0500 Boris Zbarsky bzbar...@mit.edu wrote: On 11/13/10 12:20 PM, Evgeny Burzak wrote: But , the test results looks similar for all vendors! On average the difference in processing speed is about 2-3 times (five times in Firefox 4). This is due to the fact that loops take less time (width x height * 4 vs. width x height) and arrays with less elements take less memory. Though I realize that main idea for data structure was simplicity, but in this case it seems simplicity is evil, not good. At least Gecko and Webkit implement canvas imagedata as something more like a WebGL typed array, not a JS array. So in particular, the memory usage is the same or better as for your compact array version (in the case of Gecko actually 2x better, since your compact array uses 8 bytes per color, while the native imagedata uses 4 bytes per color). Yes that gives a significant speedup due to less memory traffic and better cache locality. But this is only a problem for emulating canvas, no? And only in UAs that don't support typed arrays, say. That all seems like a transitory problem. Yes, this is local problem for canvas emulator and IE. So which format should I use? A lot of people using WinXP and IE 6-8 at this moment. There are no typed arrays, no fast JS and so on... :( But they may be our clients and don't worry about that. If they see message Script takes too much time, they say goodbye, it's not for me. This situation will be (probably) five years long or more. So while is it possible to add conversion methods to the typed array? Something like fromArray32() and fromArray8() ? Evgeny
[whatwg] fxCanvas 0.2 and some remarks about canvas spec
Hi, I have just published new Canvas stub for IE (based on flash). I'm using it in another my project - Drawform, to make it working under IE. Drawform: http://burzak.com/proj/drawform/ fxCanvas: http://burzak.com/proj/fxcanvas/ So I have some remarks about Canvas spec. I faced some troubles when using default image data, because of in old Explorers used extremely ineffective memory manager, so that I made some tests and figure out that fastest and less memory consumption is array with pixel colors encoded in 32-bit integer. Here is the test: http://burzak.com/proj/fxcanvas/tests/data-structure-comparison.html But , the test results looks similar for all vendors! On average the difference in processing speed is about 2-3 times (five times in Firefox 4). This is due to the fact that loops take less time (width x height * 4 vs. width x height) and arrays with less elements take less memory. Though I realize that main idea for data structure was simplicity, but in this case it seems simplicity is evil, not good. Another thing is reusable canvas path. I've added experimental class CanvasPath and and some related methods to Canvas context. For example: var p = new CanvasPath() // I think first argument can be string from SVG d attribute p.moveTo(0, 0) p.lineTo(10, 20) ctx.beginPath() ctx.appendPath(p) ... and so on. If you are interested in it, I can describe my idea futher... This is quite useful thing, at least for me. Evgeny
[whatwg] Canvas flash-powered implementation for IE
Hi, as Ilmari pointed out in his letter some.. hmm.. time ago [1] Canvas spec is missed method isPointInStroke(). It is _important_ thing as this will be used for generating dynamic charts and graphs. For the moment, selecting some point on a curve is not trivial problem... (Although my real intention was to make simple graphics editor for the web, but without isPointInStroke() it is impossible so far.) In addition, i allow to use flash blend modes [2] in Canvas implementation for IE [3], so could it be added in specs too? Also renamed globalCompositeOperation: * lighter - add * darker - subtract * source-over - normal project page: http://code.google.com/p/fxcanvas/ [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-December/013534.html [2] http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/BlendMode.html [3] http://burzak.com/pro/fxcanvas/tests/test_flash_blendmodes.html -- Evgen
