improvement: displaylist based drawing of Morphs

[davidedc]

each morphic.js' morph currently completely draws itself in a backing buffer, which is then blitted onto the damaged parts of the screen.

These changes below introduce a displaylist-based drawing for the FrameMorph and the BoxMorph:

https://github.com/davidedc/Zombie-Kernel-core/commit/f8b1dc0fc3128fd3ec8efd9d538d0d8c4e37885f https://github.com/davidedc/Zombie-Kernel-core/commit/73a332eff10e6b7ce8d45b3188eb995744bd2d4d https://github.com/davidedc/Zombie-Kernel-core/commit/daeef2a5a886a44d4722445986fcdb47ed64d05f

The BoxMorph is interesting because it requires the use of a further clipping mask (8 lines of code) and the rewriting of the hit test method (currently named isTransparentAt, 27 lines of code that can be refactored into a third of that size).

The advantage of having a displaylist-based redraw is a) reduced memory usage (just the desktop itself, in retina display and 800x600 , would need a backing buffer of 7.5MB) and b) it works better with affine transforms than the buffer-based method.

Note that the PenMorph can only be used on a dedicated CanvasMorph now - which exposes its "raster" nature - other morphs won't expose their buffer. I could have put a different mechanism in place where Morphs switch from one redraw mode to the other in case a Pen is attached to them but I was happy with this solution...

Some refactoring and renaming will follow, and more Morphs will be moved over to the new system.

[ghost]

Good idea, Davide! I've done it in my Starlings game via a display list called requests in StarlingsManagerMorph.prototype.step(). The display list is a list of 9-tuples.

Element #	Function
0	The image element to draw
1	The clipping X position
2	The clipping Y position
3	The clipping width
4	The clipping height
5	The X position on the StarlingsManagerMorph to draw the image
6	The Y position on the StarlingsManagerMorph to draw the image
7	The desired width to draw the image
8	The desired height to draw the image