Live data from Hacker News

Graphical User Interface Using Flutter in Embedded Systems [pdf]

static.sched.com

111–120 of 202 posts

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#111
Just in case, I've published yesterday demo build of Sciter.JS that also has binaries for Raspberry Pi (ARM32).

See: https://github.com/c-smile/sciter-js-sdk (screenshots are there too)

Some stats:

Binary size : 3.7 Mb (RPI version)

HTML: HTML5 level of markup language + "HTML Window" extensions, see: https://sciter.com/html-window/

CSS 2.1 + selected modules of CSS3, see: https://sciter.com/docs/content/css/cssmap.html

JavaScript: full ES6 specification + extras like built-in JSX, see: https://github.com/c-smile/quickjspp

Again, Sciter.JS uses time proven and well known technologies in a fraction of size.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#112

Just in case, I've published yesterday demo build of Sciter.JS that also has binaries for Raspberry Pi (ARM32). See: https://github.com/c-smile/sciter-js-sdk (screenshots are there too) Some stats: Binary size : 3.7 Mb (RPI version) HTML: HTML5 level of markup language + "HTML Window" extensions, see: https://sciter.com/html-window/ CSS 2.1 + selected modules of CSS3, see: https://sciter.com/docs/content/css/cssmap.h…

> Raspberry Pi (AMD32)

Arm32

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#113

Just in case, I've published yesterday demo build of Sciter.JS that also has binaries for Raspberry Pi (ARM32). See: https://github.com/c-smile/sciter-js-sdk (screenshots are there too) Some stats: Binary size : 3.7 Mb (RPI version) HTML: HTML5 level of markup language + "HTML Window" extensions, see: https://sciter.com/html-window/ CSS 2.1 + selected modules of CSS3, see: https://sciter.com/docs/content/css/cssmap.h…

> Raspberry Pi (AMD32) Arm32

Yeah, fixed, thanks.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#114

Just in case, I've published yesterday demo build of Sciter.JS that also has binaries for Raspberry Pi (ARM32). See: https://github.com/c-smile/sciter-js-sdk (screenshots are there too) Some stats: Binary size : 3.7 Mb (RPI version) HTML: HTML5 level of markup language + "HTML Window" extensions, see: https://sciter.com/html-window/ CSS 2.1 + selected modules of CSS3, see: https://sciter.com/docs/content/css/cssmap.h…

Sadly the recent Kickstarter [1] failed.

Does that mean open-sourcing Sciter is off the table for now?

[1] https://www.kickstarter.com/projects/c-smile/open-source-sci...

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#115
post #88

I think as Flutter matures it will change the game for native development. I'm building an app now for a well known startup and are converting their native codebases to Flutter. What is interesting is that I was able to compile the app to web with no extra work and now use that as an easy way to demo things to my client. From a cross-platform perspective that changes the game for me along with being able to build des…

I see this on dark.dev for web "Warning: While in development, web support is available in the beta channel" What is your experience? Is it OK to use this is in production app. Right now I need a web and desktop app and curious to know if Flutter can be used. But I see the Flutter web is beta quality and Flutter desktop is alpha quality as of now

Flutter Web does it's own rendering via canvas, so accessibility is off the table for now and there is no easy path to get there.

That alone should kill it for most production use unless it's an internal tool.

("should" because many apps sadly just don't care)

edit: I was wrong, see below. Glad to be wrong actually, because Flutter is great.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#116

Earlier quoted context omitted.

My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.

Embedded is a very wide field. It includes anything from thinks like (home) routers and TV set-top boxes to Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to not be battery based. I mean think about how cheap a 1+GHz ARM chip has become today.

I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#117
post #92
post #30

Earlier quoted context omitted.

I can't figure out flutter. I see so many rave reviews. But I personally tried it and strongly disliked it. The toolkit and Android Studio run horribly slow - like really slow. And the output is basically this generation's flash. Some of the samples I tried on their gallery are mediocre. Very slight, but noticeable sluggishness. Some are just terrible; the 2d transformations moves at like 7fps. Plus there are so many…

Issues with/dislike of Dart is a pretty common refrain. This project is still very early days but the intent is to bring Flutter into Typescript https://github.com/chgibb/hydro-sdk Eventually I hope to bring Flutter to C#, Haxe, and (maybe stretching it) eventually Kotlin, Java and Scala.

I genuinely don’t get the Dart hate, especially when TypeScript is the alternative. They are so similar.

But this is exactly what happened to Angular. There is a TypeScript version (fairly popular) and a Dart version (barely used outside of Google but is used for some of their biggest money making projects like AdWords).

I’ve only recently discovered Dart having come from Ruby land for the last 8 years and I could easily see Dart becoming my new go-to language in the future.

I think it’s currently criminally underrated and sadly doesn’t have a huge amount of adoption outside of Flutter at the moment but I’m looking to build my next serious web backend with it.

If you’re looking for a good introduction as to why I think it’s such a good language this video does a decent job of explaining the benefits https://youtu.be/J5DQRPRBiFI

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#119

Embedded doesn’t need wayland nor X.org. These two things implement desktop managers. Why would you run a desktop manager on a computer that runs one program only? For embedded, drm/kms is IMO better level of abstraction to base on. It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context. I did it a few times for various Linuxes using Broadcom and Mali GPUs. I’ve evaluated Flutter coup…

>Embedded doesn’t need wayland nor X.org

It depends. In this particular case, the demo seems to contain a launcher which allows to start multiple apps and switch between them. A window manager sounds preferable in this case.

Also, Flutter handles all of the Wayland/X11 implementation details. In this case it's less work to just use the already-existing backend.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#120
post #34

Earlier quoted context omitted.

An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof. Embedded includes things with GUIs, like fridges. We're not dealing with 128k of RAM. These can run basic GC'd apps just fine. Pauses really aren't any more of a concern than on desktop, or even less so.

My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.

Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors.

Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit.

Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.

Post reply on HN