Make Javascript support canvas and brush based

[marschall]

During ESUG when working with experts from Instantiations and large customers we were able to identify a dramatic performance regression in jQuery when switching on Unicode strings in VASt. The cause identified was WriteStreams on unicode strings. These are mainly caused by the following two places

• JSStream nextPutAll:
• html html: (html javascript render: [ :h | h div: 'abc' ])

The place seeing performance degradation does mostly thinks like this

$("#id").html("<div class=\"first\"><div class=\"second\"></div></div>");

The goal would be to pass along strings directly and in the end copy the UTF-8 or ASCII content into the ByteArray buffer of the response:

UnicodeString --> JavascriptEndoder --> CodecStream uft8View bytesInto:startingAt:
UnicodeString --> JavascriptEndoder --> XMLEncoder --> CodecStream uft8View bytesInto:startingAt:

The API of the JSObject hierarchy needs to remain unchanged to avoid impacting existing users.

Open:

• Performance testing and validation.
  • We do various trade-offs, mostly trading write streams for message sends and block activations. Impact is unclear, especially across dialects.
• Instead of doing the < escaping in Javascript we render to the XMLEncoder of the HTML document. This results in different output. The XMLEncoder is currently not context aware and does not differentiate between encoding an attribute value and an element value.
• Checking functional tests.
• API
  • we still have several #javascript: implementations that do wildly different things.
  • Contract between document, canvas and brush. Currently all is mixed up.

Classes of interest:

• JSStream and JSCode
• JSJavascriptDocument and JSJavascriptDocument
• JSJavascriptBrush hierarchy

This is work in progres, force pushes are to be expected. Let me know in advance if you want to push.

[jbrichau]

Thanks for working on this @marschall !

• Instead of doing the < escaping in Javascript we render to the XMLEncoder of the HTML document. This results in different output. The XMLEncoder is currently not context aware and does not differentiate between encoding an attribute value and an element value.

I have not yet familiarised myself entirely with the code changes in this PR, but the Javascript was previously rendered directly to the xml document content stream, bypassing the xml encoder. I assume we can pass that same stream to the JSDocument instance when rendering the javascript onto the xml document, also bypassing the xml encoder when writing to the stream? The renderJavascript: method now indeed wraps around the xml encoder.