New samples and features:

• /samples/graphics/test-text-drawing.htm – demo of Graphics.Text – text layout object rendering.
  
• /samples/graphs/ease-functions.htm – demo of simple graph rendering using Graphics.
• /samples/replace-animator/ – sketch of flow animator function – animates switch between different child flows in container.
• /samples/tests/test-scrollbar.htm – demonstrates overflow : scroll-indicator,  special overflow value that renders lightweight mobile style scrollbars.
• /samples/gestures/swipe.html – a la mobile, shows kinetic scroll and swipe gesture recognition. Sample works also on machines equiped by touch screen hardware.

Sciter v.2 SDK preview is available here:terrainformatica.com/sciter/sciter2-tech-preview.zip

Sciter v.2 SDK preview is available here:terrainformatica.com/sciter/sciter2-tech-preview.zip

Graphics

The whole Graphics subsystem was redesigned to use Direct2D backend. And so drawing principles were changed. Sciter v.1 uses <canvas> HTML5 alike model that implies bitmap buffer to be created for the element.

Such bitmap model contradicts CSS transforms – when you have something rendered on the <canvas> and use something like transform:rotate(15deg) the tranformation will be made on the whole bitmap rather on per primitive basis – line, rectangle, ellipse drawn.

Sciter2 uses so called immediate mode drawing thus if you define this:

someEl.paintContent = function(gfx)
{
   gfx.lineWidth(3)
      .lineColor(color(0,0,0))
      .line(0,0,100,100);
}

the paintContent handler is invoked when content layer of the element needs to be drawn.

This model is close to WM_PAINT based painting in Windows (if to think about DOM elements as windows). The difference is that gfx passed to the handler function uses all current transforms active at the moment of drawing. Including transformations applied by transform and transition CSS properties.

The DOM element supports now three paint "event" handlers:

1. Element.paintContent = function(gfx) {}
2. Element.paintBackground = function(gfx) {}

3. Element.paintForeground = function(gfx) {}

that cover all drawing layers used in DOM element rendering.

Direct2D also required to change drawing on Image’s. Once created the image will become immutable and placed into GPU space. To support this the Image constructor was changed to this:

class Image {
   function this(width,height,paintFunctionRef);
}

Thus to create image with custom rendering you will need to call its constructor providing painter function:

function painter(gfx) { ... }
var myImage = new Image(w,h,painter);

See samples in sciter2.sdk/samples/graphics/

transition:blend(ease,time,…) and friends

transition:blend now supports parametrization, you can provide ease function name, time, etc. In the same way as for atomic CSS properties.

And yet it got transitioning cousins: blend-atop(), scroll-left/top/right/bottom, slide-left/top/right/bottom, slide-over-left/top/right/bottom that use similar principles: to switch to the new state the engine makes snapshots of intial and final states into bitmaps and does transformation of these two bitmaps in various way.

The behavior:frame knows about these transitions and if they defined it applies them when switching content of the frame.

For other use cases the Element.update() function was changed to support optional stateChangerFunction parameter.

function myChangeState()
{
  this.clear();
  this.$content( <p>New content</p> );
  ...
}
someEl.update(myChangeState);

Under the hood the Element.update(changer) does these simple steps:

1. Makes snapshot of intial state of the element;
2. Calls provided changer() function that is expected to make all needed changes for the new state of the element;
3. Makes final state snapshot;
4. Starts the transitioning animation (if it is defined in CSS for the element).

If there is no CSS transition defined for such element the update() simply updates/renders the element in its final state.

The Element.update(changer) feature establishes foundation for other types of effects – expect more of those.

HTML parser

HTML parser was completely redesigned in Sciter2. With the idea to support better new DOM model and HTML5 features. The parser now recognizes these HTML5 elements: SECTION, ARTICLE, ASIDE, HGROUP, HEADER, FOOTER, NAV, MARK, PROGRESS, METER, TIME, FIGURE, DETAILS.

Debug console

All debug output was unified to use the same message format and is grouped to HTML/DOM parser, CSS parse, CSSS! and SCRIPT parser/runtime message clusters.

To setup your own debug console use SciterSetupDebugOutput() function. You also can provide "NOP" function to suppress any debug output  from the engine.

While porting Graphics functionality using Direct2D primitives I’ve tried to implement immediate mode drawing in Sciter.

Problem: as we know HTML5 mandates <canvas> to use off-screen bitmap buffer for drawings. Such model is not transform friendly (scale, rotation) as it involves bitmap transformation. So even when Graphics primitives (line,rectangle,etc.) are vector-ish the result is not a vector but a bitmap. With all consequences.

Solution:

Now you can say something like this:

function myPaintFunction(graphics) {
  ...
}
element.paintContent = myPaintFunction;

Last statement will assign your myPaintFunction to paintContent handler of the DOM element. And your myPaintFunction will be invoked when element will be drawn with graphics object already set for drawing. You can use separate paintContent, paintBackground and paintForeground handlers.

Immediate mode drawing also creates some new opportunities. Imagine that you need to write connector lines between two DOM elements at arbitrary locations. Now you can implement this using these immediate paint feature.

There are plenty of definitions of ‘closure’ term on the web. Most of them quite generic and here is my attempt to define what is the closure under the hood. Hope it will help to someone to understand better the subject.

Technically speaking closure is a data structure that combines reference to function body and non-empty list of call frames active at the moment of declaration.

Closure is created by executing some code that contains declaration of a function that uses variables from outer scopes. In this case VM (virtual machine), while executing the code, has to create not just reference to the function but closure structure – function reference and reference to its current environment[s] – list of call frames that hold used outer variables.

Here is JavaScript example of function that returns closure:

function Foo() {
   var zoo = 2;
   function Bar(p) {
     return zoo + 2; // using 'zoo' variable from outer scope.
   }
   return Bar; // returning inner function reference
}
var bar = Foo(); // here 'bar' contains Bar instance (the closure).
...
alert( bar() );  // invoking the function-closure.

In order Bar function to work it should have reference to outer call frame (the one that contained ‘zoo’ variable).

And here is an example of plain function declaration – function referred by bar uses only its own variables:

var baz = function() {
   var zoo = 2;
   return zoo + 2; // using 'zoo' variable from its own scope.
}

To represent JavaScript closure and plain function we can use following definitions (C++):

  struct Function { // plain JS function
    bytes bytecode; // executable code of the function.
  };
  struct Closure {  // JS closure
    bytes bytecode;        // executable code of the function.
    cframe* cframe_chain;  // callframe chain, used to get/set variables in outer call frames.
  };

If we don’t care too much about memory consumption then we can declare JS function as a generic class that will cover functions and closures in single entity:

  struct Function {
    bytes bytecode;      // executable code of the function.
    cframe* cframe_chain_nullable; // callframe chain, is NULL for plain functions.
  };

For any given JS function compiler can determine is it using outer variables or not. So it can tell if closure creation is required for given function declaration. It makes sense to do such detection as creation of closure is pretty expensive – VM shall move call frames from stack to the heap – convert callframes to GCable objects. If closure is not required by the nature of particular function VM should not create the closure and so heap will not be polluted by unused call frames.

I’ve added support of gradients in H-SMILE core. On the right are some of renderings with debug output (line with arrow) showing gradient vector used in each case.

Sciter v.2 SDK preview is available here: terrainformatica.com/sciter/sciter2-tech-preview.zip

Radial and linear gradients are supported.
Implementation of radial gradients follows this draft: dev.w3.org/csswg/css3-images/#radial-gradients
Implementation of linear gradients in H-SMILE core is a (very) super set of this: dev.w3.org/csswg/css3-images/#linear-gradients

Transition (animation) of gradient values is also implemented.
Only transition between two compatible gradients is supported.

See test-linear-gradient.htm and test-radial-gradient.htm in /samples/basics/ folder of the SDK.

You can download Sciter v.2 SDK preview from here http://terrainformatica.com/sciter/sciter2-tech-preview.zip

/bin/sciter.exe in the archive is a demo application to play with. Its sources are in /demos/sciter/ folder. After start you should see something like this:

Note: this version works only on Vista/W7 as it uses Direct2D/Write graphics backend. Aero and W7 Basic DWMs only for a while.

New features in this version:

• Direct2D/Write graphics backend – pretty fast on some operations. Expect animations to work faster.
• Support of CSS 2D Transforms Module Level 3: http://www.w3.org/TR/css3-2d-transforms/ – everything except matrix() function. Will add it later if needed.
• Internal DOM representation was redesigned to avoid need of that ugly <text> element injected by the parser. DOM is more standard now and in principle H-SMILE core can pass ACID2 test (if I will have a time to tweak it for that). DOM is represented by Element and Node entities. Node wraps text and comment nodes in HTML.
• TIScript got support of "tagged n-tuples" data type. http://en.wikipedia.org/wiki/N-tuple with optional tag (a.k.a. name).

Some observations about Direct2D/Write:

Font rendering

Font rendering as I’ve mentioned already is significantly different in GDI and DW. Small an basic UI fonts looks better in GDI mode. Larger fonts are better in DW. For white text on black background with small and medium font sizes the GDI rendering is the only option I think. Just load /samples/basics/test-font-rendering.htm into the Sciter and you will see what I mean.

I was forced to introduce font-rendering-mode proprietary property for applications to be able to tweak this aspect.

Direct2D performance

While it is good on medium/high-end graphic cards it may behave very badly on low-end graphic cards or when there are applications on desktop that do graphic intense operations. Notably running Adobe Flash may affect speed of rendereing of other applications. That is not only about Sciter per se but other applications. Windows Live application suite is an example of graphics sensitive application. You may notice frame drops in animations inside Windows Live Mail or Messenger.

It appears as Direct2D/Write is a foundation for future high-DPI displays. As for now that font-rendering-mode workaround is the must I believe.