> Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late.
Not a few milliseconds, but a few dozen seconds might be a different story. While it might be hard to predict or measure an exact number, your deadline is however long it takes for the user to equate it to "forever" and kill the process / leave the website / uninstall the app / etc..
A 'real time' OS does not mean fast. It is simply that the OS can promise an application/driver that it will get the processing time that it requests. e.g. a nuclear power station controller might use a RTOS to guarantee that the emergency shutdown process can be completed in under a certain number of seconds, regardless of whatever else is going on.
In general, being able to make these kind of promises means that the OS has to be pretty conservative about the code it allows to run, and a 'best effort' OS or some 'soft' RTOS is probably going to be faster or more efficient.
In terms of UI responsiveness, I'd bet that crappy software running on a 'hard' RTOS can still manage to feel sluggish, because the UI delays probably aren't actually in the OS itself.
Not a few milliseconds, but a few dozen seconds might be a different story. While it might be hard to predict or measure an exact number, your deadline is however long it takes for the user to equate it to "forever" and kill the process / leave the website / uninstall the app / etc..