[Vm-dev] SqueakJS

Jerry Bell jdbellomm at gmail.com
Sun Nov 23 04:51:37 UTC 2014


Hi Bert,

>
> That shouldn’t have been necessary … I specifically wrote it using the
> original syntax so it would work even in old images where the Compiler does
> not know about named primitives yet. What exactly didn’t work?
>

If I use the original syntax, I just get an "Error: a primitive has failed"
error.  I have no idea what might cause it.

>
> I'm assuming this syntax is more like what you would use in more modern
> Squeaks?
>
>
> Yes. But what I used should have worked fine.
>
> 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]]
> 67
>
>
> Neat! I should steal that as example :)
>
> The HTML5 Canvas text rendering code is several times faster than
> DisplayText>>displayOn:.  It also results in nice, smooth anti-aliased
> text*.
>
>
> I tried to make the JS bridge to have as low overhead as possible without
> actually cheating. I hope the Smalltalk deities will forgive code like this
>
>
> https://github.com/bertfreudenberg/SqueakJS/blob/master/utils/JSBridge-Core.package/JS.class/instance/doesNotUnderstand..st
>
> https://gist.github.com/bertfreudenberg/3046cb8d5bb5177ea07f
>
> Then again, it’s TSTTCPW, and it does.
>

Seems to work fine to me!

>
> 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?
>
>
> MVC strongly assumes that it has access to the pixels on the display. For
> example, if you open a menu, it renders the outline and text items on the
> display. Then, to highlight an item, it does not re-render it, but draws a
> rectangle in xor-mode, reversing all pixels. This is very efficient …
> provided you have direct access to pixels. Which you don’t have on a canvas
> - reading back pixels is slow. Canvas wants to be treated as a write-only
> surface.
>
>
OK, that is good to know.  Does Morphic have the same assumptions?

> 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.
>
>
> Yes. The whole Squeak screen is a bitmap, and only displayed on the HTML5
> canvas using putImageData. No other canvas drawing commands are used.
>
> 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?)
>
>
> Balloon2D is used in more modern images, mostly to render TrueType fonts
> and color gradients. But again it draws to Squeak’s display bitmap.
>
> (Also, after the paper was written, I replaced that Balloon2D
> implementation with the original, which does not use an HTML canvas, but
> instead renders scanlines into the bitmap directly. Turns out to actually
> be faster than reading the pixels back after drawing them with canvas
> commands)
>
> 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?
>
>
> I’m not sure what your actual goal is here. Why bother with the canvas at
> all? Why not just build a real HTML interface?  To display a text you would
> create a <div> element and insert the string. That would cost almost no
> time at all, and the browser will deal with all the rendering needed.
>
>
You go and build the ultimate run-everywhere object engine, and then you
want to go and clutter it up with HTML? :)

My questions on Canvas accelerated Squeak graphics are just random
thoughts right now, before I go and start real work on my first real Squeak
MVC web app. I am by no means a web expert, but whenever I am trying to
build web applications it feels like I'm dealing with a tottering tower of
kludges.  I think HTML may be fine for building a web page, but Canvas is
the future for interactive web applications.   I don't want to spend my
time trying to trick CSS into doing what I want, or trying to compensate
for various subtle differences between browsers.  I just want to have the
same complete control over what my web application does as I would if I
were building a desktop application.   I think Canvas has the potential to
provide that.

But, Canvas is pretty low level, you can draw pretty text but text layout
is up to the programmer - and  there aren't many good Canvas frameworks out
there yet.  Most assume you want to build a game.   There are a few
exceptions, for example ZebKit looks pretty nice: http://www.zebkit.com,
and SpreadJS is a nice fast spreadsheet component implemented using Canvas:
http://wijmo.com/products/spreadjs/  - I've used SpreadJS in a UI with a
few hundred thousand cells and it feels like a desktop app.

I considered building a version of Morphic in Amber, but I didn't get too
far- it was going to be a lot of work.  I had pretty much decided to build
my next app in pure JavaScript using ZebKit.   And then I saw SqueakJS...
Squeak in Canvas, easy to take advantage of existing JavaScript libraries,
and fast enough to use for a real-world web app on an iPad (at least in
MVC).  Good enough for me for now!

A couple more observations: one of the 'killer features' of Dart when
running in a Dart VM is object memory snapshots, to speed up application
loading - you already have this in SqueakJS using regular old JavaScript.
Also, SpreadJS is nice, but un-minified it weighs in at 6.39MB, and
minified it is 1.83MB.  The entire minimal-MVC image is 1.61MB.  I don't
think download sizes will be too much of an issue for SqueakJS web apps!

In summary, I don't really need any of the fancy Canvas accelerated
graphics right now.  But, I think SqueakJS has a lot of potential, far
beyond being just a way to run Squeak images in a web browser.  It seems to
me that something pretty close to SqueakJS could be a lot like the Web
should have been from the beginning!

Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141122/9ae7156c/attachment.htm


More information about the Vm-dev mailing list