jdbellomm at gmail.com
Sat Nov 22 14:10:24 UTC 2014
BTW, I've been using the "minimal-MVC" image from
https://github.com/downloads/smarr/RoarVM/minimal-MVC.zip for my SqueakJS
experiments. It's still really fast, but I think it is a more
comfortable image to work with.
I was able to get your bridge code working in the minimal-MVC image by
changing the primitive calls to this syntax:
I'm assuming this syntax is more like what you would use in more modern
Here is the result of a quick experiment:
dText := 'The quick brown fox jumped over the lazy dogs back' asDisplayText.
Time millisecondsToRun: [1000 timesRepeat: [dText displayOn: Display]] 659
canvas := (JS document getElementsByTagName: 'canvas') at: 0.
context := canvas getContext: '2d'.
context font: '14pt Arial'.
context fillStyle: 'black'.
Time millisecondsToRun: [1000 timesRepeat: [context fillText: 'The quick
brown fox jumped over the lazy dogs back' x: (canvas width / 2) y: 120]]
The HTML5 Canvas text rendering code is several times faster than
DisplayText>>displayOn:. It also results in nice, smooth anti-aliased
I'm still trying to learn more about the low level graphics in Squeak
(specifically MVC). I don't have a very good understanding yet. Do you
think it is feasible to retrofit Canvas based optimizations such as drawing
text into the existing Squeak graphics engine in order to make an image run
faster under SqueakJS? Or would it require building a separate graphics
engine specifically designed to take advantage of the Canvas API?
My general understanding of the Squeak graphics engine is that there is a
display bitmap (Here, Display), and everything is drawn in-image and
eventually blitted out to that Form. Somewhere down there, when someone
wants to put a string on the screen, the image draws individual letters on
an offscreen Form somewhere, and then those bits are eventually blitted to
the Display form.
It appears to me that in SqueakJS, the final Display is an HTML5 Canvas,
and almost everything else is in-image Squeak bitmaps. That is my
understanding of how most (all?) Squeak ports work. (I did read in your
paper that the Balloon2D plug-in is also implemented using Canvas, but I
guess this is not used much for the basic graphics system?)
If Forms were Canvas instances instead of normal in-image objects, it seems
to me that it should be possible to use Canvas operations on them to draw
lines, text, etc using the fast, probably hardware-accelerated Canvas
support in the browsers. But I don't know if it would be possible to
retrofit that into the existing graphics stack without basically requiring
a full rewrite of much of the graphics code.
It is probably naïve to think that it might be possible to build a handful
of classes like CanvasForm, CanvasBitBlt etc that implement the same
interface as the existing Squeak classes but use HTML5 Canvases to do most
the work; and then switch them out for the existing native Squeak
classes. But if such a thing were possible, how much faster do you think
everything could be?
Thanks again for the bridge!
*draw one time if you want to see the smooth text, by the end of 1000
repetitions the text looks pretty ragged from the repeated antialiasing!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev