2022-09-21 05:35:40 KipIngram: re 400ms, it's an interesting design decision in BeOS (and Haiku) that there is no "hourglass" cursor 2022-09-21 05:35:53 KipIngram: if you do something, it should "do something" even if it's not ready 2022-09-21 05:37:46 huh, what happens? 2022-09-21 05:40:03 eris[m]: it'll at least start to draw stuff 2022-09-21 05:40:06 or show a progress bar 2022-09-21 05:40:12 give some indication that stuff is happening 2022-09-21 05:40:40 ahh 2022-09-21 08:40:16 Well, it just strikes me as something that could have been an "OS level issue" back in the Halt and Catch Fire era, but really should be an application issue only these days. Fast as we are there's no excuse for the OS to be doing anything user-interface related that takes noticeable time. 2022-09-21 08:40:35 Including booting up, in my opinion, but oh well. 2022-09-21 08:42:04 And that should only be SOME applications, that do very very intensive computations on large amounts of data. 2022-09-21 08:42:26 Most computer behaviors should be "perceptually instantaneous." 2022-09-21 08:43:52 Then whas gordonjcp mentioned above would be just for those few applications functions that do take time, and what he described really was an interesting way of approaching it. 2022-09-21 08:54:17 KipIngram: in practice, moving shitloads of data on and off disk 2022-09-21 08:54:32 KipIngram: and basically anything related to video, but that's back to moving shitloads of data on and off disk 2022-09-21 15:20:14 Yeah, I do think (like I said) that there will be some applications that can stress modern processors to the "you're gonna notice the delay" point, but those are the only ones I excuse. I do NOT excuse the OS - it should be designed in a way such that anything involving that much data is backgrounded and not put in a wait path. 2022-09-21 15:20:29 I know that in certain applications you've got to finish the hard stuff before you can go on. 2022-09-21 15:20:40 I just don't see where that is in the "OS sphere." 2022-09-21 16:29:50 KipIngram: yup