Coverflow has become a de facto visualization standard for the presentation of collections of images, be it covers or portraits.
There are a number of implementations for usage on web pages (e.g. this one) but the usable ones require Adobes Flash and thus won’t run on the iPhone.
When looking for HTML5 canvas based implementations I found this promising implementation based on the YUI library.
Though workig, it has three major drawbacks: It is rather overengineered and difficult to tweak, it uses YUI (whereas I prefer the more lightweight jQuery) and it performs poorly with image sizes bigger than thumbnails.
After trying to change the code for a while I decided to do a reimplementation in jQuery. The result can be seen on the MomoFlow demo page. Here are two screenshots:
CoverFlow using canvas and jQuery
Quicklook mode
The used 3D transformation is superbly described on the YUI blog .
My implementation caches the rendered canvases per rendering angle. Further speed increments are made possible by adjusting the mesh width used for the slicing transformation depending on the achieved framerate.
The result performs beautifully in recent Safari, Chrome and Opera, decently on Firefox. It also works flawlessly on the iPhone. Keyboard control is coming soon.
I do still need help on IE, maybe the image composition is too demanding for ExplorerCanvas?Â
The code is available on github: http://github.com/momolog/momoflow.
Comments and improvements are very much welcome!
September 4, 2009 at 11:05 am · Filed under Javascript
Javascript allows naming and assigning functions at the same time like:
var vname = function fname() {}
The function name fname is available only inside the function as a local variable:
var vname = function fname(){
console.log(typeof vname); // function
console.log(typeof fname); // function
}
console.log(typeof vname); // function
console.log(typeof fname); // undefined
If we “redefine” this local variable inside of the function, we get a strange effect:
var vname = function fname(){
console.log(typeof vname); // function
console.log(typeof fname); // undefined !!!
var fname = 1;
console.log(typeof fname); // number
}
console.log(typeof vname); // function
console.log(typeof fname); // undefined
Obviously the interpreter sees the variable declaration var fname on entrance into the function and does not provide the function variable at all.
In what they call a “backwards compatibility change” the prototype core developers have introduced some changes to the prototype Hash class.
A little history:
From version 1.5 the Hash class started behaving a bit differently because now the Enumerable methods where copied into the Hash prototype instead of into the instances, as before. That helped minimize the memory footprint but introduced incompatibilities and removed the possibility to patch Enumerables methods because after patching Enumerable one would have to manually copy its methods into all “inheriting” classes again.
To my understanding that is in conflict with the dynamic inheritance in prototype-based languages like javascript.
See this thread for more info.
Now with 1.6. things get worse. The Hash object is not an JS object with added functionality anymore, its a wrapper around one.
The following code will work in 1.5.0.2 but not in 1.6:
test = $H({a: 1, b:2});
alert(test.a); // -> 1 in version 1.5
Instead, in prototype 1.6 you have to write test.get('a') to get to the property “a” of the underlying object. In case you need the whole object, there is always test.toObject() to the rescue. Bye bye, consise and short notation.
I feel the developers forgot what made prototype so wildly successfull: Its beautiful concept of enhancing the built in objects, not wrapping them.
I consider leaving the prototype world alltogether and will switch to mootools.
The following article describes ticket #3592 in the RoR Trac and explains a proposed solution.
Prototypes Enumerable mixin class does not properly respect the mixees internal format. For example the reject and findAll methods, operating on Hashes, return Arrays instead of Hashes.
var a = $H({a:1, b:2, c:1, d:3});
document.writeln(a.inspect().escapeHTML());
=>#
var b = a.reject(function(val){ return (val[1]==1) });
document.writeln(b.inspect().escapeHTML());
=> [['b', 2], ['d', 3]] // !!! should be hash
var c = b.findAll(function(val){ return (val[0]=='d') });
document.writeln(c.inspect().escapeHTML());
=> [['b', 2], ['d', 3]] // !!! should be hash
In Ruby (from which the inspiration for the Enumerable Mixin stems), the reject method does return a hash, not an array, when operating on an hash:
The patch requires all classes that want to mixin Enumerable to define two more methods similar to _each: _new, which returns an empty object of that class and _add, that adds an element. Enumerable mixin thus needs to make no more assumptions about the internal structure of its mixee class.
