Show HN: GuiLite – Tiny UI framework, runs on MCU without OS | Hacker News Reader

Show HN: GuiLite – Tiny UI framework, runs on MCU without OS

github.com

355 pointszorro_young48 comments

Open articleView on HN

The examples of GuiLite and those of Littlevgi (posted in this thread) all look a little outdated and messy.

And I can understand this. Most programmers aren't designers.

But if you know why it looks outdated and messy it can help to create better looking products.

The reasons are: lack of alignment and padding / font sizes all over the place.

To make your product look good there are simple tricks you can use:

  * Only use one size of padding (and multiplications of it).
  * Align your items horizontal and vertical.
  * Try to use one font family and maybe only 3 font sizes.

The above is why frameworks like Bootstrap work. They are all about alignment and consistent use of space.

One more sin I would add here would be using too little paddings in general. If you have enough space, try to double (or 1.5x) all of them and you will probably see an improvement.

True. A good minimum might be 0.5 * normal font size.

I like to see projects like this pop up because it's so easy to fall into a trap of accepting input latency that other more bloated UI frameworks bring.

As we all know, Electron is really bad in this department but it's not limited to Electron.

I recently installed native Linux and the problem exists there too. Gnome terminal has a MASSIVE amount of input latency compared to xterm. Even worse than the difference between Electron and any non-Electron app in Windows.

I wish more people embraced and went all-in with UI frameworks that were optimized for reduced latency. IMO reduced / low latency input is the most important feature for a terminal or code editor.

Agreed. For school I have to use Visual Studio on my laptop and the input lag is just absurd. (Surprisingly Code is pretty good.)

Yeah VSCode is pretty solid in this regard for an Electron app but I hope they continue to try and optimize it.

It's still very noticeably delayed compared to something like the default WSL terminal or xterm but VSCode has much lower key press latency than Hyper and a few other Electron terminals like Terminus.

They've re-written many performance sensitive components in C++. Thats why code performs really well. They've done a great job!

I think Atom has components in C++. VSCode is Javascript only.

oh yes sorry! I stand corrected.

The code performs really well because, as you say, they've done a great job engineering it. However, they've specifically stated a few cases where C++ wasn't pursued. An example: A while back I read a blog post [1] talking about how they analyzed why the text buffer was causing OOM errors for certain files. It's a really good read, discussing drawbacks of the initial array of lines data structure, and how they came to use the "piece tree" data structure, and some of the tradeoffs therein.

[1] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

I was astounded when I learned the VSCode was an electron app. I used it for almost 2 years without a clue. Very impressive.

Interesting, I definitely believe you after reading Dan Luu's posts a year or so ago on keyboard and terminal latency.

However I use mate terminal every day and it feels like it responds instantaneously, even over a USB keyboard connected to a dock connected to a laptop.

Maybe as long as the latency is below a certain threshold it is no longer noticeable.

It's a tricky thing to perceive because there's a lot of variables at play.

A lot of LCD monitors have 50-75ms of input lag. That means you don't even see what you type until 75ms afterwards so you might not even have a chance to see how a low latency application behaves. Then on top of that, there's the human factor. Some people are just more sensitive to this sort of thing.

The monitor I use happens to have about 13ms of input lag (verified with camera tests) which is pretty much as good as you can ask for with an IPS panel. I wrote all about picking monitors for programming at https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo....

The difference is night and day when typing in an application that's not efficient vs one that is. Even typing in this comment box on HN feels like I'm typing in mud because Chrome's input lag is horrendous compared to xterm, WSL Ubuntu terminal or any other application that doesn't have a million layers of UI framework abstractions piled on.

If you're curious, one of the developers from the WSL Ubuntu terminal went into great detail on why their terminal is so fast. It's at https://github.com/Microsoft/console/issues/327.

The sad thing is, I've opened high input latency issues to a number of other terminals and the author of those terminals often come back saying "nah, your computer must be broken, otherwise everyone would be complaining" even after I supply them video proof. I guess that's what happens when you live in a world where everyone has low end monitors and are used to using Electron apps all day.

Yep my gear, especially the dock, probably enforces a minimum latency on everything.

The only time latency is noticeable to me is if I can type faster than displayed on screen. I type around 50 wpm so the computer doesn't have to respond that quickly to keep up. Online I found that equals 250 cpm, or ~4.2 cps, lets say it has 240ms per keypress to not fall behind. Plenty of time.

Your dock is a glorified USB hub, unless it's a more expensive Thunderbolt dock, in which case it's a glorified PCIe switch. In either case, the added latency is completely imperceptible to humans, and in the latter case, pretty hard to measure from userspace software. The dock is not even close to being the largest source of latency in the chain. The components that can be responsible for tens or hundreds of milliseconds of latency are the display, hard drives and overloaded SSDs, network, and bad software.

Yes, usb-c probably thunderbolt. Checked my dell external monitor, folks say they have a small lag. Don’t notice any difference between it and laptop monitor.

i recently purchased a monitor and was looking for a way to figure out input lag without a camera setup.

one recommendation was to test your reaction time [1] on a known low-latency display. mine old one was a 1080p 21.5" Dell IPS LCD. I was worried that a 2k or 4k display would introduce lag, though at 60hz anything within 16ms g2g will feel the same and the 1440p Viewsonic i got advertised 15ms.

Best reaction time (~190ms) over multiple trials did not change after switching to new display. Not scientific, but certainly enough to catch something as large as 20ms+.

[1] https://www.humanbenchmark.com/tests/reactiontime

For semi-new monitors you can find super in depth reviews at http://www.tftcentral.co.uk. They often include input lag. I highly recommend that site to get the true input lag of your monitor (without having to resort to your own tests).

g2g typically measures the response time of the monitor which is a different thing than input lag. Most manufacturers won't even list input lag on their specs even though it's one of the most important attributes of a monitor since it affects everything.

I could see the reaction time being a fun way to get an average with enough samples. I did 3 sets of 5 and it was 201, 194 and 196 as the average. But I think reaction time and being able to perceive input delay are different skill sets. I'm almost 40 so my reaction time sucks, but I can still notice a delay difference in apps when pressing a key.

The best way to measure end-to-end latency is an Arduino with a light sensor, with the Arduino programatically injecting USB events. I made an Amazon shopping list[1] a year ago. I hope to rework my code and post a blog soon.

[1] https://www.amazon.com/ideas/amzn1.account.AGSZP5AWBGH7772O3...

If you're into this sort of thing I recommend reading this article: http://www.tftcentral.co.uk/articles/input_lag.htm

It goes into a lot of depth on input lag and how to measure it accurately. The site also happens to have recorded input lag numbers for hundreds of monitors.

In the article it mentions using photo sensors and oscilloscopes as the best way to get a reading but they settle on using a special type of stopwatch test that gets results that are nearly the same.

I did such a thing a while ago at my last job. I guess it still works https://github.com/strawlab/lagtest

This is for embedded development (e.g. a gui for your washing machine), not a replacement for Electron, Qt, GTK or what have you.

Yes, GuiLite could embeded in Qt, MFC... And you also could run without them, even without OS.

So this is a framework to X? Framebuffer? Wayland? Everything? How does this software fit into all other software out there?

It is for embedded development - e.g. your car radio or washing machine. You wouldn't use this for desktop.

BTW, it is written right there in the title "runs on MCU ..." (MCU = microcontroller)

For Linux: It render the framebuffer directly -- you can check the code GuiLiteSamples/HelloParticle/BuildLinux/main.cpp

For MCU: It call LCD driver for rendering pixel -- you can check the code GuiLiteSamples/HelloParticle/BuildSTM32F103/main.c

For Qt, MFC, iOS, Mac: It build UI as a memory bitmap, and map it on picture Widget of Qt/MFC/iOS/MacCocoa

anybody else find the JS on the site they host their demo video on weird? uMatrix shows stuff being loaded from 127.0.0.1. Not a web person, so I'm confused...

The multi language example for Thai looks like it is rendering wrongly.

Proper rendering: ความสูง

Similarly for the Hindi, where the character combinations are not properly “merging”. Multiscript support (especially Indic scripts) is hard but unfortunately this current stage is unusable.

However, this framework looks promising so for instances where multiscript is not needed I’ll be interested in seeing how this one checks out.

Don't complain. Contribute.

I've worked on text rendering in the past, and the amount of subtleties in how each language is rendered and the exceptions/code paths that must be implemented to properly support said languages is not insignificant. Mind you, I say this as a native speaker of these languages. I don't want to imagine the amount of effort and work that would be required to support a language I don't speak. Doubly so if I'm not being payed for it.

If you need support for a language you speak, help the developer by implementing and contributing the support yourself.

PS: This isn't aimed at you specifically, but to those who criticize projects for lack of language support without understanding the effort required.

Folks, downvoting me isn't going bring your language any closer to being supported. If you have a sound argument against what I stated, please voice it instead.

It's not useful advice. One does not simply add complex script support to some simplistic text drawing codebase. You have to take on dependencies to codebases at least an order of magnitude larger than GuiLite itself (wc harfbuzz/src/*.{h,hh,cc} is 86kloc and doesn't include the Unicode functions). Thus, it's a major architectural decision to support complex scripts at all, and to figure out how to do it.

> One does not simply add complex script support to some simplistic text drawing codebase.

We don't disagree here. This is the reason why rendering support for non-Latin scripts is usually abysmal on most software like op. It's why authors need help and usually won't do it themself.

> Thus, it's a major architectural decision to support complex scripts at all, and to figure out how to do it.

That's all the more reason to contribute to the project.

> It's not useful advice.

Perhaps it isn't very practical, but someone has to do it. It's also better than the alternative of just complaining without contributing towards a useful result.

This is actually a super-interesting problem. The complex scripts require "shaping", which increasingly is done by HarfBuzz. Companies used to maintain their own proprietary implementations, but that's increasingly not a good idea. A problem is that HarfBuzz is a large, complex piece of software, entirely because OpenType is complex and not well specified (there are a ton of edge cases).

I did some research a few years ago on defining shaping by composing several simple finite state machines together, and am confident it could be made to work. The problem is, it doesn't work with existing fonts, the rules for shaping would have to be redone. But for fonts shipping in an embedded device, this would be entirely practical, and would be a lot faster and a lot less code than a solution based on HarfBuzz.

I'd need some incentive to complete this research. If someone wants to pay for it, please get in touch.

What about compiling existing OpenType fonts to state machines in combination with the shaping rules? That's something we're thinking about for our Rust implementation :)

It's not as easy as it looks, but probably can be done. The research I was doing was very much pure transducers, but with a couple of twists (the one I'm proudest of is alternating between forward and backward passes, which makes certain things like matra reordering much easier). There is some work in this space by Monotype as well.

Looks quite nice.

Thanks

bad design

Please refrain from unconstructive comments! How would you make the design better?

Any idea for improvement? Thanks

If you are looking for something that will run on even smaller embedded devices I highly recommend LittlevGL. I have used it to throw a UI on a few projects, and found it to be surprisingly easy to get going, and fairly responsive long as you can run it in buffered mode.

https://littlevgl.com

That's really great, thanks!

This seems fantastic!

Thanks, this one also supports the Esp32, which is great.

The demo has a Chinese name: 天女散花(means: fairy scatter blossoms)

Seems very interesting; nice work for sure. Any chance of a browser port?

Yes, we have. You can build & run GuiLiteSamples\HostMonitor\BuildWinCmd\WinCmd.sln

You will find the UI be displayed in your browser.

Reply on news.ycombinator.com