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:
Element.paintContent = function(gfx) {}Element.paintBackground = function(gfx) {}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:
- Makes snapshot of intial state of the element;
- Calls provided changer() function that is expected to make all needed changes for the new state of the element;
- Makes final state snapshot;
- 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.