|
|
Subscribe / Log in / New account

Point of a fast UI response

Point of a fast UI response

Posted Aug 20, 2016 4:50 UTC (Sat) by gmatht (guest, #58961)
In reply to: Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police) by Wol
Parent article: Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

Seriously. As a user, what's the point of having a fast UI response, if it's actually doing sweet fa under the covers?
Of the top of my head:
1) If the computation takes longer than expected having a still functioning Cancel button is great.
2) Immediate feedback that the interaction was accepted, so we don't think "I can't have pressed hard enough" and try again.
3) So that we can enter data while the last request is still processing. E.g. imaging that it takes 4 seconds for me to type "lwn.net" on my tiny keypad and 3 seconds for Firefox to load, if I we can do both at the same time, Firefox would seem to load instantly.
4) Don't break users abstractions. If I push a page up I don't expect the page to stay still and then suddenly shoot up seconds after I have touched it.
5) Immediate Feedback is important for some tasks. For example if I want to push the word "Fuchsia" to the top of the screen it will be immediately clear if I have pushed far enough (unless the GUI lags).
6) Users usually find a responsive GUI "nicer". Even when it doesn't make it faster to use, life is to be enjoyed. A buttery interface is less unhealthy pleasure than a buttery cake!

Also if a phone needs to do hard core computation, it is often best to push it out to the cloud where it won't drain the phones battery.
And oh, for those people who said that providing a fast UI should be a high priority, Linux (the kernel) doesn't agree with you. Last I knew, the defaults prioritized throughput over responsiveness.
This is a little circular, since we are discussing whether Linux's priorities are appropriate for mobile devices. Linux is mainly tuned for servers where latency can't be less than your ping time anyway.

Even for desktops it is not clear this is a good default. About once a month I find my self I find myself power-cycling Linux because I accidentally opened a couple too many tabs, and the reset button was the only thing that would respond within a hour. This kind of jank never happened on my old 6502 machine which was obviously very fast much faster than me... it had an 1MHz processor! Even if I could just reserve 1% of my CPU and RAM so that top, kill, and perhaps even xterm would be fast even under heavy load that would be great.


to post comments

Point of a fast UI response

Posted Aug 21, 2016 17:55 UTC (Sun) by flussence (guest, #85566) [Link]

>Even if I could just reserve 1% of my CPU and RAM so that top, kill, and perhaps even xterm would be fast even under heavy load that would be great.
That sounds like exactly the problem the “Automatically cgroup processes by tty session” hack added to the kernel was supposed to solve…


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds