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.
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.
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.
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.
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.
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.
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+.
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.
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.
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.
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...
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.
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.
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.
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.
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:
The above is why frameworks like Bootstrap work. They are all about alignment and consistent use of space.