Personal computers today are usually hundreds of times faster, and have thousands of times more memory then the computers in the time when operating systems with graphical user interface started to become common.

However, even on today's fastest machines and modern operating systems one can encounter situations when the most basic controls become non-responsive or extremely slow. The system grinds towards a halt, and sometimes even the mouse cursor stops moving.

You can't even navigate the file system because its windows are frozen: if you try to open a menu, it is being drawn line by line and pixel by pixel, and by the time it is fully drawn, it is usually too late. This on a machine which could otherwise render high-resolution lifelike 3d simulations.

This would all be avoided if the Os would reserve a certain amount of fixed resources solely for its GUI. Why isn't this implemented, or if it is in some manner, why not fully? I doubt that the answer would be "to not waste resources when they become critical", because in such a situation, freeing up the reserved 0.1% won't save you (I guess even doubling the resources wouldn't save you most of the time), but having fully responsive controls in the task manager, file system viewer, system settings, etc. might have saved you.

closed as off-topic by JonW Sep 8 '13 at 17:29

  • This question does not appear to be about user experience within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    This is more of a software/hardware engineering question rather than a UX question. – DA01 Sep 6 '13 at 18:18
  • @DA01 : can you then suggest another site to migrate this? – vsz Sep 6 '13 at 18:23
  • The Programmers SE or Software Quality Assurance & Testing SE.. Or maybe even Stack Overflow. – Arman Sep 6 '13 at 18:31
  • 1
    I agree with @Arman [Programmers] seems a good fit – Marjan Venema Sep 6 '13 at 19:31
  • 1
    For computers, there isn't an actual boundary between what you consider GUI which should be responsive and the rest. When an application is waiting for a resource, it freezes, whether it seems frozen or seems to be react, yet waiting in the background, depends on how the application was designed and on whether there are enough resources for that specific application (which can be 1 of 100s running simultaneously). The OS is no exception, if your applications are consuming a specific resource, the system will have to wait for it to be released. – Danny Varod Sep 6 '13 at 21:04

Reserving resources for the GUI would not help if other resources of the computer are occupied. Modern computers balance the need for resources themselves following a predetermined priority list, where the GUI is one among others.

Would it make you feel better about your computer if you could move the mouse around on the screen, but when you interacted with the computer it would not respond?


Because the OS can just help, applications get it wrong and users get it wronger

(notice: this answer is mostly windows-focused, although the general concepts apply to most GUI systems)

The key is that UI operations are just "regular" operations run by the code of the program.

All the UI actions done in response to some event (window repaint, widgets response to clicks, ...) boil down to a loop that asks messages from the operating system and dispatches them to the correct procedure. Both the message pump, most of the plumbing and the UI code run in the same userland thread, which is commonly called the UI thread (actually you can have multiple UI threads in some cases, but it's a mess and I've never seen anyone doing that for real).

Thus, if a process is hogging the CPU, it can happen that the other processes never get a chance to run, so the message pumps remain blocked and UIs become unresponsive.

So, usually the whole thing depends from process/thread scheduling; kernel architects have produced tons of scheduling algorithms (Linux is often said to have the "scheduler of the week" ), some favoring UI responsiveness; Windows in particular gives a priority boost to the thread of the current active window, and have a switch to favor interactive use or server use (it mostly governs the length of assigned CPU time slices).

Nonetheless, no algorithm is perfect, especially since they strive to find a balance between system responsiveness and allowing CPU-demanding applications to do their job.

Also, there are often problems with novice programmers who have fundamental misunderstandings of about how the message pump machinery works. A typical case is when you ask to some program to do something and its GUI hangs until the operation terminates; here some programmer decided to run a lengthy operation inside a message handler, blocking the message pump and thus the whole GUI of the application.

Another problem comes from "power users": often messing with processes/threads priority can have tragical results: setting CPU-intensive operations to "high priority" ("yay it'll run faster!") results in rarer scheduling of regular priority threads, and thus to GUI slowdown/hang.

Thus, to summarize:

  • UI slowdown is normally a matter of bad CPU scheduling;
  • it's difficult for the system to let just the UI run since it's governed by the various message pumps, so you can't just "let the widgets be responsive" - either you let the whole UI thread run (which may do lots of other stuff), or you don't.
  • to keep a responsive UI applications must be smart and keep the main thread just for UI, and delegate CPU-intensive or blocking tasks to low priority threads, so that when the CPU is scarce most of the CPU time available will go to keeping the UI going;
  • users that mess with process priorities without knowing what they are doing deserve what they get (especially idiots that put heavy processes to "real-time priority", which is even above system-critical processes; almost always the situation ends in forced reboots); on a system that must remain responsive heavy processes must have low priority, the UI will keep going and the heavy process will still get 100% CPU if there isn't other work to do.

Many, possibly most, things stemming from user input must be performed synchronously. This is by design. A user action, e.g. button click, invokes an action which often causes an internal state change and then the display to update to reflect that change. To accept input before display is updated, upon a view that is basically obsolete, would open things up to many errors and inconsistencies. In most cases the internal change and display update are fast enough to not be an issue, but in a multitasking virtual memory system the application designer doesn't have control and extraordinary events (e.g. running out of available RAM causing the OS to swap things to/from the disk) can interrupt the usually quick response. Software engineers take great pains to keep the UI as responsive as possible but there's simply no way to ensure it will always be responsive in a multitasking virtual memory system.

Of course sometimes it is simply bad application engineering that allows the UI to be less responsive than it could be, but the operating systems have had years and years of refinement and optimization applied towards keeping the UI responsive.

Not the answer you're looking for? Browse other questions tagged or ask your own question.