(Question) Building lite variant for raspberry pi

[martinlombana]

What are the steps to build the lite variant for raspberry pi, as there is no a main lite executable that we can just pass an html to, in order to test, right?

(Moreover, I would be interested in building or spawning the whole thing, wrapped with pysciter, as you know I am a fan of python :) ). I don't know if just building with pysciter, and changing/loading the .so file for the lite one would be enough, or are there other steps involved or to consider?

Thanks in advance,

[c-smile]

There is "Discussions" section for questions (and you are here). Thanks in advance.

Why do you need lite? What are you trying to achieve with it?

Sciter Lite is used inside OpenGL or DirectX windows as an HTML layer for example.

In order to use it you should be able to create/configure OpenGL or DirectX window/surface.

[martinlombana]

(Yes, sorry about that. I missed that section. I will post simple questions there from now on. My bad). Basically, as I will not need any desktop at all, in order to create small kiosk apps that can be spawned directly without a desktop as regular linux app that draws directly. Like a game. My aim is to avoid any superfluous layer.

…

--

___________________________________ *Martín Lombana* *TODOLOGIC.COM <http://TODOLOGIC.COM> | APPS & MORE* *+34 633 63 02 35 | *+34 946 759 137 *INSTAGRAM *→* @ <https://instagram.com/todologic>TODOLOGIC <https://instagram.com/todologic>*

[c-smile]

regular linux app that draws directly. Like a game.

Lite version will work for you then. With it you can render stuff in screen buffer (as a bitmap) or on OpenGL surface if you have one.

[zcream]

Is there an example of using the Sciter.lite C/C++ API to render HTML/CSS to an offscreen buffer? This buffer does not need to be shown on a browser window - the user can retrieve it for further processing.

[c-smile]

Yes, here it is: https://github.com/c-smile/sciter-sdk/tree/master/demos.lite/win32-bitmap

That's sample from old Sciter.TIS SDK but it can be used with Sciter.JS as it is.

The sample renders HTML/CSS loaded into Sciter.Lite instance on DIB : https://github.com/c-smile/sciter-sdk/blob/master/demos.lite/win32-bitmap/plain-win.cpp#L314

[martinlombana]

Also, I don’t see the variant for arm64/rpi in bin.lite.

[c-smile]

I don’t see the variant for arm64/rpi in bin.lite.

I don't see either :)

It takes quite some time to build Sciter on RPI. Normally customers do builds on their side with options/configurations they need.

[martinlombana]

I see. And do you have an example or the docs/steps to build sciter lite for raspberry pi, so I can test the build and see the performance of that variant? :) Thanks.

[martinlombana]

Just to clarify (can be useful for others), in order to be able to build for raspberry pi, to try the capabilities, I need to purchase the indie+ license beforehand? (Or is there a way to build in order to just test it, in the free tier?) I do intend to purchase the license for support of the project. I just wanted to validate the capabilities beforehand, to see if it has the basics that I need.

[martinlombana]

Also, maybe this in the rpi4 modelB can make a difference?

https://www.google.es/amp/s/www.cnx-software.com/2020/02/03/raspberry-pi-4-opengl-es-3-1-conformant-vulkan-drivers/amp/

[martinlombana]

Quote:

"That means that any Linux programmed using OpenGL ES 3.1 API should work out of the box, although in some cases there may be issues/bugs that were not detected by the test suite."

[martinlombana]

Also, as reference:

https://www.raspberrypi.org/blog/vulkan-update-were-conformant/

I don't know if this is useful or not, but just in case...

[c-smile]

Last time I tried Sciter.Lite was on RPI 3.
RPI 4 may behave better, will see. I'll try to build Sciter.Lite in this week.

[martinlombana]

Great! Thanks so much! Can't wait to try it and validate it on my side for my needs.

[martinlombana]

As an alternative, do you think in this 2, openGL sciter-lite version could run without issues?

https://www.lattepanda.com/ -> Seems to be x86 64 bits pc.

My objective with the stack that I am looking for is:

1. Linux (Ideally Ubuntu), command line, no OS desktop, I don't need it, and I don't want it to consume space, ressources and/or added complexity

2. Being able to spawn the lite version of sciter, for full performance (I don't need windows, and If I need them, I'll present "my own" with the sciter-js)

Do you think this would be a suitable machine? (Although pricier than a pi, for sure).

[c-smile]

Have no idea really.

I've tried while ago to run Sciter/Windows on Intel Stick: https://www.intel.ca/content/www/ca/en/products/boards-kits/compute-stick.html and it showed pretty good performance. But that's with Windows and DirectX backend.

In principle you can use GLFW (or SDL2) for testing OpenGL performance.
Sciter.Lite renders on OpenGL surface that they provide.

So you generally don't need Sciter.Lite to check performance on RPI, check:
https://www.raspberrypi.org/forums/viewtopic.php?t=276207
https://www.raspberrypi.org/forums/viewtopic.php?t=243707

[martinlombana]

I see. I will check it out. When I mean test the lite version, is in order to validate that what I want to do can be done, the responsiveness, etc.

I saw that there is port of WPE: https://samdecrock.medium.com/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362

That shows incredible performance on a raspberry pi. But, of course, it's quite the "whole package" with a lot of redundant things. And that is in a Raspberry pi 3 (not the 4)

https://www.youtube.com/watch?v=3WqEAXa1yEg
https://www.youtube.com/watch?v=_KsCrg0kyac

I would still prefer sciter, over all that. I don't know how do they do it exactly but it seems like they are getting very good frame rates and performance.

Overall, otherwise, you think that spawning the regular sciter (non lite version) with a window manager without getting to the desktop might have better perfomance then?

[c-smile]

Well, it really depends on screen size you are targeting.

If that's about something around 1024x768 then any solution will work - sciter-gtk.so on RPI uses stock Cairo that is pretty adequate for such screen sizes. You can try your ideas in usciter / sciter-gtk first. Cairo uses CPU rasterization but that could be even faster in some cases and on those screen sizes.

The only difference is that Sciter.Lite can render as a) directly in video buffer (with CPU rasterization) as with b) Skia/OpenGL (with presumably H/W acceleration at least of some operations).

And note that in case of b) even small area update on screen will involve full screen update (that's how OpenGL works).

[martinlombana]

No. It would need to be suitable for a 2k display (43 inches or more) 3840 x 2160. Because that is becoming the norm, and it's quite difficult to find large tvs with 1080p anymore. They all come with the 2K/4K (that I find a bit worse, actually in image quality).

So yeah, looks like I need sciter.lite for my use case.

[c-smile]

I've managed to assemble Sciter.JS.Lite for Raspberry Pi.

That is on 3840x2160 screen and in window.

As I said OpenGL performance on RPI depends on screen size - it is a sign that some OpenGL operations are made on CPU side.

For example, on 1920x1080 resolution, that window renders with 60 FPS.

My test shows that Sciter.Lite FPS rate closely matches performance of Chromium on RPI on this test: https://www.testufo.com/, at the end Chromium and Sciter.JS use same graphics backend (Skia)

Try to make Chromium full 4K screen and you will have 10 FPS or so.

[martinlombana]

Nice!

Thanks!. Did you try with a rpi4 4GB of ram, or with a rpi3?

I think if I can output at 1920x1080 / 60fps and the TV upscales it nicely (to be seen) It would do the trick and I would be quite happy with it, actually.

Did you compare it to the WPE port or just the regular chromium? Because the WPE webkit port is different from the regular chromium.

[c-smile]

That's on RPI 4, with 4 Gb RAM.

Sciter.JS.Lite is published on GitHub (v 4.4.6.6).

You definitely will need to find best suitable OpenGL configuration. Quite a lot of discussions on RPI forums discussing it.

On RPI Sciter.JS uses OpenGL 2, on desktop Linux OpenGL 3.0+

[martinlombana]

I see. So any PC, with x64 architecture and ubuntu, will perform better, because of OpenGL 3.0+. Right? Like small PC-s with simple Amd Ryzen graphics, or Intel Graphics + Ubuntu?

I think I'll pass to that configuration if the raspberry pi is problematic.

Also, if using sciterpy, should I just swap the .so files for the lite version, and it should work directly, drawing to open-gl without the need or a desktop-gui, or is there anything else to consider first?

Thanks!

[c-smile]

Also, if using sciterpy, should I just swap the .so files for the lite version, and it should work directly, drawing to open-gl without the need or a desktop-gui, or is there anything else to consider first?

Not directly. sciterpy relies on creation of window and loading HTML/CSS in it.
And Sciter.Lite is a windowless engine. You will need to create either window or be able to bind OpenGL with screen buffer directly. From Python. For example with GLFW/Python: https://pypi.org/project/pyglfw/ in this case you may use code from this sample pretty much as it is.

[martinlombana]

Thanks. In the case of that example, how do I comunicate or stablish a connection with the sciterpy version? By compiling a .so file from that example and "providing" that new .so to sciterpy?

[c-smile]

Whole Sciter API is exposed as single structure with function pointers ( a.k.a. interface ).

That structure gets "cracked" here : https://github.com/sciter-sdk/pysciter/blob/master/sciter/capi/scapi.py
But it seems it does not support Sciter.Lite ( sections under WINDOWLESS define ).

So all functions of Sciter are available in Sciter.Lite. except those that are in #if !defined(WINDOWLESS) ... #endif sections.

[martinlombana]

@martinlombana that example is just an example of using Sciter library. You will have to recreate it in Python.

Yes, I know. But I still can't grasp the steps involved to to that. I can recreate the same thing in python with the pysciter, based on the .so file? Or I need the actual C sourcecode in order to do that?

[c-smile]

You will need either:

1. to port that sample from C to Python using https://pypi.org/project/pyglfw/
2. To recreate functionality of that sample by other Python means.
3. To do not use Python but JavaScript and use that C sample as it is. JavaScript is capable to do everything that Python can do. If you care about performance and running these things on limited machines then Python is not quite suitable for the task.

[martinlombana]

You will need either:

1. to port that sample from C to Python using https://pypi.org/project/pyglfw/
2. To recreate functionality of that sample by other Python means.
3. To do not use Python but JavaScript and use that C sample as it is. JavaScript is capable to do everything that Python can do. If you care about performance and running these things on limited machines then Python is not quite suitable for the task.

I see. The last sample you pointed me to, is an executable file. How do I see the source code of that example that uses the .so file? I couldn't find it.

Moreover, I could always spawn the non-lite version, as an alternative, with xwindows manager. In that case, things wouldn't be drawn by opengl, but with cairo, and in a window (although not attatched to any desktop, just managed by the very own window manager). You also pointed that performance for UI things was faster that way anyway, because of the partial screen redraw.

As for using python or JS. I would still use JS for a lot of things in the UI side, which is what I usually do. But I wanted to get the full controll of the program and package it with pyinstaller, without any dependencies for easy distribution.

Therefore, my aim to make it work against openGL with the lite version, and control automatic updates with the main python executable. I know it would be better if everything was a C program, but I am not versed in C (yet) so that is a limitation for me. Also, python is faster for development and prototyping, and I am using it too in microcontrolers, therefore my obsesion with having it onboard, besides the fact that I like it. For instance, a pygame app, can run without a desktop GUI, without starting X on linux. It uses SDL and writes directly to the framebuffer.

[c-smile]

I see. The last sample you pointed me to, is an executable file. How do I see the source code of that example that uses the .so file? I couldn't find it.

Link to its sources was here:: #62 (comment)

But I wanted to get the full controll of the program and package it with pyinstaller, without any dependencies for easy distribution.

C is better in that. You even can do monolithic executable that you can just copy on target machine without any packaging. Also C/C++ does not require you to run one more VM on limited device.

Also, python is faster for development and prototyping,

Probably, but there is a 90%/10% rule - you will do (prototype) 90% or your app fast but rest 10% of your app (effective video output for example) will take 90% of dev time.

It uses SDL and writes directly to the framebuffer.

You can use Sciter.Lite with SDL too. GLFW and SDL are on par if to speak about desktop apps.

But again, not clear why do you need Python for that. SDL is native library and Sciter is native library.
So Python is used as a glue to get output from one native function and pass it as input of another native function.
Same can be done using JS that is actually a Python but with different syntax.

[martinlombana]

But again, not clear why do you need Python for that. SDL is native library and Sciter is native library.

We have clients that develop, themselves, also in python for a broad range of apps. Porting all that code, which is not UI code, to sciter-js, is not possible. We still need python and a lot of already developed modules and routines. And I don't want to use a small webserver to connect to a python backens, because that is overkill and leads to problems. For instance, we are in the need of getting rid of chrome in an electron developed app, for ui, that comunicates this way with python. And I wanted to rewrite the UI in sciter, but have the option to use direct calla to a main python program. A program that must be alive and running constantly with a "supervisor" role (not a set of commands or calla to scripts that can be called once to do something).

For small apps, I will not use python at all, as default sciter-js will do just fine.

For biger apps, and integration with other complex, already developed by my client apps, I have no other choice. Having direct calls to python is key, in my particular case.

It is not only because I want to use python "yes or yes" because I like it.

😌

Anyway, for the windows side of things, the bindings exist, and they are usable as you told me, so that is plus.