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.

Whole epoch of perfect quality in visual design and art of its implementation has passed away. Sigh.

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.

Almost each month I see discussions about character encodings on various software forums. Most of the time these are pure urban myths, legends, hoaxes and rumors. Actually I am surprised how many software developers simply have no idea about the subject.

Here is my attempt to define all these terms in single place and in compact form:

1. windows1251, utf-8, ascii, koi8, etc. are all “transport” encodings of UNICODE code points. Encoding defines format of transmission(or storage) of a text – meaningful sequence of characters of human language(s).
2. UNICODE code point is a 21-bit number – index of a character in UNICODE database (table).
3. Each encoding is characterized by its code unit.
4. Code unit – smallest non-dividable element of the sequence. In most of encodings code unit is a byte – 8-bit number. But there are exceptions. For example: ASCII-7 – 7 bits, UTF-16 – 16 bits, UTF-32 32-bit integer.
5. Encoding can be full – covers whole UNICODE range (e.g. UTF-8) and it can be partial (for example ASCII) – maps subset of UNICODE code points to code units of particular encoding. Strictly speaking any official encoding like ASCII, Windows-1251, etc. is a UNICODE encoding if it has official and/or well known definition of code units mapping to UNICODE.
6. Encoding may have variable number of code units per single UNI-code: UTF-8, UTF-16, GB18030, etc. And there are “fixed” encodings with 1:1 mapping of code unit to UNICODE code points: ASCII, ISO/IEC 8859-1, Windows-1252, and so on.

About UCS-2 and UCS-4.

• UCS-2 – is a 16-bit subset of big UNICODE table. Sometimes is used as a synonym of BMP range – Basic Multilingual Plane.
• UCS-4 – is a full range of UNICODE table (32 bits number where 21 bits are used).
• UCS-2 and UCS-4 are not encodings. These are just names of historic ranges of character codes (UNICODE code points).
• As an examples:
  • JavaScript standard (ECMA-262) defines that String instances represent sequences of UCS-2 (!) codes. So character code in JS is limited by 0xFFFF.
  • In my TIScript string is a UTF-16 sequence so it can operate by full UNICODE range. Thus str.length can be larger than number of characters in string (e.g. for some Far East texts). str[i] will give you number from 0 to 0xFFFF – value of UTF-16 code unit. But if you will write:

      for(var codePoint in "...str..." )
         stdout.printf("%d ", codePoint);
    

    you will get sequence of real UNICODE code points from string.

And that is pretty much it. Not a rocket science, is it?