Latency of Haiku GUI interaction and general first thoughts

Hi all, this is one of my first posts here. In one sense, it is my first real post, as I actually spent the time to try out Haiku to see if it lived up to the claims. If anyone here has seen it, I wrote the “Insidious Creep of Latency Hell” article which appeared on the front page of Slashdot recently (and found the Mandelbulb if that rings a bell). I mentioned Haiku too obviously, and at the bottom of the latency article, timed various GUI operations for Linux and Win7. Every millisecond matters.

Latency is one of my biggest beefs with Windows or Linux. Whether it’s opening a file requestor or clicking a button, everything should be instant, less than 30-50ms preferably. I was really happy to find this to mostly be the case in Haiku. However, it’s not perfect, and I’m going to say why, and it’s everything to do with mouse button down versus mouse button up.

Imagine typing into Notepad or StyledEdit and the characters only register on screen when you lift your finger off the key, rather when you press it. It would be bad, and would feel wrong. That’s what it feels like when mouse-button-up is used instead of mouse-button-down for various GUI interactions. Notice how clicking top menubars does it the ‘right’ way. The effect is instant, and it feels good. I understand that on some occasions, ‘mousedown’ is used to drag components - that’s fair enough. However, mouse-button-up is used unnecessarily in the following cases:

  • Selecting a program from the “applications” dropdown under the main ‘feather’ menu
  • Maximizing a window
  • Selecting a file in a disk window (yuck)
  • Clicking radio buttons

These are just a sample - I’m sure there are many others. According to the speed of the person clicking, they add at least about 40, and up to 250 milliseconds to any action.

In a related action, you need to double click a folder to enter it. On the Amiga, only one mouse-down click was required, and it feels much better. I understand you need a way to highlight a folder for copy/paste purposes, but RMB (bringing up the menu at the same time) or even the middle mouse button can be used here. In the Notepad++/EditPlus/Visual studio text editor, you can also click to the left of lines to highlight that line, so an approach like that could be used also/instead.

Any thoughts on this - I’d love to see Haiku not just very fast, but LIGHTNING fast.

Switching to some praise now, I love how in Haiku how RMB sends a window to back. Also how RMB lets you drag the position of the window’s scrollbar ‘inplace’. This is a feature sometimes only found in Amiga apps, and I’ve always wished it to reappear. Whoever suggested/implemented that for Haiku - I give my hearty congrats. Aesthetically, the 3D bezel effect is really nice in general (see say, Wonderbrush for a good example). The slightly darker shade of grey also used for the GUI is also much more sensible, unlike the too-bright-white that Windows 7 employs by default (which makes the real white barely different).

On the more negative side, there are lots of things which I would request (single-click launchbar/program switching, better font anti-aliasing, resizing windows from all edges), and even a bug or two, but I won’t post them here, as it makes more sense to put in the suggestions subforum. Metadata is another issue I want to speak about, but I probably need to install Haiku to my HD, rather than just run the live CD to learn about that more before I comment on it.

Cheers all for this amazing OS! I hope it develops and overtakes Windows in the future.

I find the mouse configuration to work just fine, however under prefrences you can change the double click and single click speed. Double click is a very normal user paradigm, don’t try retraining computer users, it’ll just piss em off.

Welcome aboard, lets hope haiku does kick windows in the ass, If you have a large audience, why don’t you compare window/linux/haiku latencys. I for one would be very curious to see what those are.

I think in many of these instances the goal is to prevent a n accidental click, also is the structure of the menu such that it could tell if what you’ve clicked on is an application or a window and then process the act of a mouse down vs mouse up accordingly? i admit I don’t know.

I’ve enjoyed reading your “Latency” article, lots of nice technical data, and I agree fully with your observations.

I’ve implemented a custom GUI using OpenGL, and also run into the MouseDown/MouseUp issue you’ve mentioned, and it’s unmistakable that for certain elements (eg. buttons), MouseUp is the preferred responder, since it allows the user a grace period to cancel the request (by moving the mouse away from the button, then releasing the pressed button). Other elements (like sliders) work on MouseDown. I’ve learned that you can not a-priori accept MouseDown for every element, since after some more thought, you learn about other usage scenarios and cancellation policies. And as you’ve pointed out, if an action leads to MouseDragged, then you have no choice but have to wait for MouseUp to process.

Lots of ex Amiga people joined BeOS, and by extension Haiku. We’re still around, and “Responsiveness” is our mantra. I only boot into Haiku maybe once a month these days, but I’m constantly amazed at how intuitive and responsive the system is on the same hardware compared to the other bloat out there. However, I do realise that the other systems are doing more. Whether those system are doing more than what’s necessary is another matter, but in the end of the giant OS war, the winner will be the most balanced system.

Thanks for your analysis, small details count, i’m a bit short on time so i’ll answer briefly.

Concerning “Selecting a file in a disk window” it’s been fixed as a side effect of my rewrite of the mouse tracking in Tracker (the desktop/file manager). Unfortunately it’s not part of the alpha3 release as it was too late to be safely included, however you can try it with the nightly images or by building yourself.

I suppose the other cases you mentioned could be fixed too. However, it is very important that you file an enhancement ticket listing these problems on so that it’s not forgotten and get the attention of devs. This is the quickest way and official channel to get things done and the project is very thankfull to people contributing there.

Concerning double vs simple click, you’ll face different people with different tastes, but with tablet computing getting more popular, we’ll have to provide different click/gesture configurations anyway, so any research is welcome.


Thanks all for the feedback! I’ll respond to all comments in this one post:

Sounds good! I was going to also say that it would be great to have a couple of extra pixels for each window frame to help the accuracy tolerance. Default would be good, but a preference (x pixels) obviously would be nice anyway. Not sure if the speed of Haiku relies on a more hard coded GUI design though…

Even I’d have to get used to it. I wouldn’t recommend if I didn’t think it was better generally though. I think sometimes new concepts take a while to get used to, but can be ultimately preferable on the average. It would have to be done right though…

Though the article received many visitors at the time, it is a niche topic generally, and traffic to that page now is tiny (10 a day or so). I’d certainly love to do something in future though.

[quote]Concerning “Selecting a file in a disk window” it’s been fixed…
…I suppose the other cases you mentioned could be fixed too. However, it is very important that you file an enhancement ticket listing these problems on so that it’s not forgotten and get the attention of devs. This is the quickest way and official channel to get things done and the project is very thankfull to people contributing there.[/quote]
Nice one for the file selection fix! I think the best ideas should be submitted, hence it would be nice to see a few more opinions (I can point them to this thread).

Actually, I think a nice idea would be to open folders and even files (!) with one click as long as the filename itself is clicked. Anything else such as the associated ‘date modified’ or ‘file size’ area would just highlight the file/s instead. This is a fairly big user change, but it really fits with the philosophy of Haiku’s speed I think. A lesser but still effective option would be to use the middle button to open with one click. This would be good for many, though my wireless middle mouse is a pig to press. As always, these new features could always be optional, and not necessarily default (at least not at first :wink:

We’re agreed on the dragging issue. However, in the other cases, Mouse-press-up is probably not needed, and to explain why is going to be tricky, but let me try:
The fraction of a second that it would’ve taken to ‘cancel’ the user’s mistaken click in the mouse-press-up system could’ve simply been used for the brain to process things instead. A analogy would be like wanting a system that waits 10 seconds before sending an email. You get the 10 second latency, but you could have spent those 10 seconds yourself before clicking ‘send’. Only habit, and the few times that it’s ‘saved’ you have registered as it being a good thing. But if you were to change to mousedown, you would simply adjust to waiting that 0.2 seconds longer on the average before pressing say, the radio button. Or zero seconds longer if you were confident about the press. At least with the mouse-press-down system, you’re given the option, whilst the mouse-press-up has a forced latency. Sorry that I’ve taken a while to explain this - it’s really fidgety to explain, but hopefully you’ll see what I’m getting at.

In addition to the latency on mouse-press-up, most modern applications have an undo, and finally, I can’t count the number of times I’ve zipped over to a button, pressed it, but then was too quick to move my mouse to another place to do something else. In those cases, the radio button click wasn’t registered. Anyway, this could all be optional anyway…

Yep, I think in the end, even if it’s in far future, the core of the OS has to be spot on. Build something on a dodgy foundation and it affects everything else. That’s why I think Haiku (or something like it) has a real shot.

Many good observations, twinbee!
WRT to “resizing windows from all edges”, this has recently be added. CTRL+ALT is a window management keycombo (see the user guide). While holding it a left click-drag anywhere will move the window, right click-drag will resize depending where the mouse pointer sits.


Just an FYI - the Haiku Media Server was originally written with the specific purpose of provide low latency multimedia (sound, video, images) access. It was recently recoded by Stippi and has the promise of providing truly amazing performance for Haiku native applications. So when we get someone to write or update audio editors, video editors, image editors, viewers, etc we should have something really impressive to show off.

There is a lot of untapped potential here, but we need some native applications.

I just created an enhancement ticket for this - here’s hoping!