Lightweight inline vector images in Sciter.

I think all web UI designers time to time experience need of drawing of non-trivial shapes directly in CSS.

Lack of such feature leads to appearance of far from being optimal solutions: icon fonts (hi Awesome), crazy attempts to draw non-trivial shapes using CSS border artifacts and excessive use of additional pseudo-elements: `::after` and `::before`. People are writing tons of essays on the subject. See how far it can go. Phew…

Thus I’ve decided to add inline vector images to Sciter.

Consider this SVG element:

 <path d="c 50,0 50,100 100,100 c 50,0 50,-100 100,-100" fill="#000" />

Note that d attribute value. It defines path and use pretty simple yet powerful format. But just to draw that simple curve SVG requires bunch of DOM elements to be created around it. Not that lightweight for that simple purpose.

And here is what I did in Sciter: it now supports so called path urls that use exactly that svg::d format:

div {
  background-image: url(path:c 50,0 50,100 100,100 c 50,0 50,-100 100,-100);
  background-repeat: no-repeat;
}

Note that url above, it is just a content of that d attribute, just prepended by “path:” part.

Here is an illustration of such inline vector images:

inline-vector

And so you can draw anything in CSS now, any shapes and icons you want.
As a bonus: such images can be created in any visual SVG editor like Inkscape or Adobe Illustrator. It will require manual copy paste from SVG source into CSS but still.

Landed in revision #3955 for upcoming v.3.3.1.12

Adding inline C functions to Sciter :)

As a response to WebAssembly initiative I am thinking about adding native inline C functions to Sciter.

// that is inline C function declared directly in script:

function getAverageColor( image ) C {
   typedef struct {
     byte r;
     byte g;
     byte b;
     byte a;
   } rgba;

   rgba*    pix   = image_pixels(image);
   unsigned total = image_pixels_count(image);  
   rgba*    pix_end  = pix + total;

   unsigned int r = 0, g = 0, b = 0, a = 0;
   
   for(; pix < pix_end; ++pix )  {     
     r += pix->r;   
     g += pix->g;
     b += pix->b;
     a += pix->a;
   }

   rgba out;
   out.r = r / total;
   out.g = g / total;
   out.b = b / total;
   out.a = a / total;
   return out;   
}

And so we can call that function in script when we will need to get maximum performance:

var img = new Image(w,h,element);
var averageColor = getAverageColor(img);

Such functions will be translated on the fly into native code and so executed as fast as possible.

Huh?

Making API thread safe

I have refactored public API to be thread safe.

It means that all API functions can be called from worker threads directly.

When the engine detects access from non-GUI thread it marshals the call to be executed in GUI thread
and blocks the worker thread until UI will execute it. Therefore if you have more or less massive UI updates from worker threads it is still desirable to use approach outlined here.