Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We have UI models that allow us to through long-running operations onto a background thread so that we can render perfectly animated hypno-toad cursors Or, more currently, perfectly animated cute-wait animations to keep people entertained while long-running operations complete. (Only a matter of time before wait-animations incorporate mini-games to play while while you're waiting, I think). But...

I'm not sure we have UI models for dealing with more complicated asynchronous operations on a document model though.

Old versions of Microsoft word used to run pagination and line-breaking on a background thread. The UI would keep a couple of lines around the edit cursor up-to-date, with precisely page layout for anything more than a couple of lines after the edit cursor running asynchronously. (It probably still does, but we probably notice it less these days).

And various elaborate schemes for keeping local and cloud object models synchronized asynchronously.

Oh. And I guess we have compilers and editors that collaborate to take snapshots of code when a compile starts, while allowing editing to continue, and to run Intellisense analysis in the background in the face of continually updating edit buffers. Incredibly complicated stuff, done mostly by brute force of intellect, I think.

Beyond that, I don't think we have a general theory of what to do in user interfaces when there isn't enough CPU to go around.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: