Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graphical User Interface Using Flutter in Embedded Systems [pdf]

static.sched.com

Post reply on HN
Print view View original

151–160 of 202 posts

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

#151

Post by Const-me »

emersion wrote: post #142
Const-me wrote: post #130

Earlier quoted context omitted.

> the demo seems to contain a launcher which allows to start multiple apps and switch between them. If the count of apps is small, and all of them are written by you, it's not terribly complicated to pass exclusive access to display across processes. Only becomes too complicated if you want many apps updating their windows at the same time, or support third-party apps. > it's less work to just use the already-existin…

> it's not terribly complicated to pass exclusive access to display across processes. You're just starting to re-invent the Wayland protocol. You need to pass input too… and more of Wayland re-invented. >desktop environments are huge Weston or Cage doesn't really qualify as huge. Also, I think you underestimate the work to write a program using KMS and libinput. It's pretty easy to write a toy app, but writing a soli…

> You're just starting to re-invent the Wayland protocol

I think the main feature of WL is simultaneous multi-tasking. If you don't need that, a desktop is redundant. That's why Google made their own proprietary DM for android instead of adapting what Linux had.

> You need to pass input too

I haven't tried but I think multiple processes are fine reading from the same /dev/input/event[n] at the same time, they'll just get the same events. Therefore they may process or ignore these based on whether they rendering or not.

> I think you underestimate the work to write a program using KMS and libinput

I did it several times, both for hire and for lulz: https://github.com/Const-me/Vrmac/ drm/kms pieces are in C++ and not in that repo, but raw input is there, was easy: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li...

> writing a solid framework is something else

Depends on the scope. If you only need left to right languages, couple keyboard layouts out of the 204, etc., it's reasonable.

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

#152

Post by chgibb »

proverbialbunny wrote: post #101
chgibb wrote: post #92

Earlier quoted context omitted.

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.

>Eventually I hope to bring Flutter to C#, Haxe, and (maybe stretching it) eventually Kotlin, Java and Scala. Like this? https://pub.dev/packages/starflut "A new flutter plugin project, which supports flutter to interact with other scripting languages such as python, java, ruby, golang, rust, etc. It is easy to use, supports android and ios platform." Full warning, I have zero experience with this plugin and zero exp…

Thanks for the link! I actually haven't seen that project before.

As far as I can tell, starflut appears to offer basic script running with pass through of primitive types from Dart -> guest languages.

Hydro-SDK strives to offer far deeper integration between Dart -> guest languages up to and including extending from Dart classes in guest languages, and passing instances seamlessly back and forth with little overhead.

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

#153

Post by diskzero »

c-smile wrote: post #137
izacus wrote: post #68

One of the main bonuses of Flutter is also its underlying design - it really just needs a Canvas to render to and not much else. This makes it easy to port to other platforms (even web) and it allows you to have a very lightweight embedded system running a builtin app. This makes debugging easier as well, since you can just write the app on desktop, test in emulators and then deploy. Our experience matches Sonys in t…

If Canvas means pixmap/bitmap (2D array of pixels) then unfortunately that's not enough in modern world. On high-dpi monitors you must use GPU to offload rasterization of drawing primitives from CPU to GPU. Otherwise the only job your will do is drawing at 100% load - say "hi" to batteries and other apps on the desktop. That's why I am supporting in Sciter as plain pixmap targets as GPU based ones: Direct2D/DirectX,…

Flutter has a Skia-based backend with GPU acceleration. A bitmap/pixmap solution would be the worst-case scenario and probably only occur on an esoteric platform where GPU support is absent.

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

#154

Post by diskzero »

okareaman wrote: post #125
apta wrote: post #59

Earlier quoted context omitted.

> and I think by that comparison, Flutter wins hands down. I'd be interested to hear your experience about why that is.

I really like C# and .Net for getting the job done but Balzor runs Mono .Net in Wasm and the startup time is brutal for the public internet. 2 to 3 seconds. This leads me to believe Blazor is targeted at corporate intranets on high speed networks where you have a ready supply of C# programmers

I developed a fairly complex site using Blazor, starting back in the earliest releases. It was easy to deveolp for and having the depth of .Net (more and more features became available each release) was nice. I also found the build size to be an issue and wouldn't suggest using it for general purpose website. Microsoft really needs to focus on reducing the binary sizes.

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

#155

Post by leppr »

novok wrote: post #104
yjbanov wrote: post #42

Earlier quoted context omitted.

(disclaimer: I work on Flutter Web) We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.

How about stuff like being able to select text in the UI? I tried a couple apps in https://gallery.flutter.dev/#/ and none of the text was selectable like in web and desktop interfaces

Proper links and mapping of navigation to browser history are also important for any content-focused webapp. Keyboard navigation is incomplete too (some elements like dropdowns).

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

#156

Post by mwcampbell »

Hixie wrote: post #145
blub wrote: post #140

Earlier quoted context omitted.

It is both surprising and unsurprising... Unsurprising because it's not the first time Sony bet on an unusual language ( https://news.ycombinator.com/item?id=1938652 ) and people on HN were similarly excited. Days later the initiative was put on hold and the domain doesn't even resolve today. I think it's safe to say that their initiative did not end up as a huge success. Surprising because according to their own pre…

Flutter's Wayland support is used by Google for a consumer product with millions of users. (source: I work for Google.)

Does that mass-market consumer product have proper accessibility support, e.g. for blind users? If so, is that somehow implemented within the Flutter UI, or parallel to it (e.g. as a separate voice interface)?

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

#157

Post by pkphilip »

singhrac wrote: post #27

I also, independently, started writing an app in Flutter for fun (no experience in mobile/desktop GUI work, several years since I've worked in front-end web). I can give a list of pros/cons that probably overlaps what you've heard: Pros: - The toolkit feels fairly mature and not too hard to parse. I think there's a lot of "this class works with defaults and breaks otherwise" feeling, though the core components are ro…

Some of the drawbacks I have noticed with flutter:

1. One of the biggest problems with flutter is the IDE integration for the design aspects. In my opinion, the development experience is much worse than Xamarin, .NET/Mono, Delphi, Lazarus etc.

2. The documentation is not very good and can be quite out of date.

3. The components are mostly all UI/layout related. There aren't good components for DB integration etc.

4. I have noticed is that between version upgrades of flutter, there can be multiple problems - but this is not surprising that flutter is still quite new.

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

#158

Post by b20000 »

Const-me wrote: post #83

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…

Totally agree with your view. "It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context." - interesting, I've been wanting to get rid of the X server and use opengl or vulkan on a mali GPU fullscreen without needing X or wayland. do you have example code online somewhere for this?

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

#159

Post by blinkingled »

izacus wrote: post #93
blinkingled wrote: post #81

Earlier quoted context omitted.

I think for extremely limited capability embedded devices it makes sense to have Linux kernel + Wayland - but anything modernly new Android will do fine. Honda uses it in their in-dash entertainment systems for example.

What do you gain with Android on a small device (that's not a computer screen like a head unit) though? You just add a significant maintenance burden because you need to tear out all the phone parts from the OS which make updating and patching it really hard.

In Sony's case aren't they talking about a device with screen though? The screenshots show a screen with launcher and app icons.

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

#160

Post by chinmaygarde »

c-smile wrote: post #137
izacus wrote: post #68

One of the main bonuses of Flutter is also its underlying design - it really just needs a Canvas to render to and not much else. This makes it easy to port to other platforms (even web) and it allows you to have a very lightweight embedded system running a builtin app. This makes debugging easier as well, since you can just write the app on desktop, test in emulators and then deploy. Our experience matches Sonys in t…

If Canvas means pixmap/bitmap (2D array of pixels) then unfortunately that's not enough in modern world. On high-dpi monitors you must use GPU to offload rasterization of drawing primitives from CPU to GPU. Otherwise the only job your will do is drawing at 100% load - say "hi" to batteries and other apps on the desktop. That's why I am supporting in Sciter as plain pixmap targets as GPU based ones: Direct2D/DirectX,…

You're right but that is not how Flutter works. Flutter supports rendering using multiple client rendering APIs (OpenGL, Metal, Vulkan) and the embedder gets to pick one. Based on that decision, the embedder then has to handle WSI to provide the Flutter Engine a render target. In the case of OpenGL, it is a framebuffer object that passes all completeness checks. The engine will render directly to it. This way, the framebuffer backing stores are completely under the control of the embedder and the engine does not have to do unnecessary render to texture passes. The engine will never allocate an array of pixels in host memory when a GPU backend is selected. As you said, that would be slow and inefficient. We typically go to great lengths to minimize the device (and host) allocations and render target switches when rendering.

Disclosure: I am one of the authors of the Flutter Embedder API.

Post reply on HN