> Which could very well do it's stuff in a different thread and execution context given the actual payload such a system needs to transfer from a wordprocessor

> Which could very well do it's stuff in a different thread and execution context given the actual payload such a system needs to transfer from a wordprocessor is trivially small. It's a blocking operation, so doing it in a different thread will not magically mean the requesting application can get it faster. Besides, this is already done in a different thread, but it increases the load of updating the UI. > Which can be considered a one more defect of the system which I forgot to lambast. Sandbox my wordprocessor, let me operate in realtime in unsafe environment and once I'm moving something out of the sandbox, then do the analysis. Which is already what is happening, but all data in and out needs to monitored. But regardless, it cannot operate in an unsafe unrestricted environment, because that implies full access to the memory. > This argument is moot. Pretty UI:s are computationally a tenth or hundredth of the complexity of an AAA title. Unless one does it wrong. And if the system does not provide enough horsepower, provide a backup! Reduce the computational load! Cut the transparencies, freeze the animations, etc. As I started to say, you have some merit to the argument, but I simply pointed out that modern UIs require multiple orders of magnitude more computational power to render. And providing a fallback is yet another cost of developing, and for the most part not something people/companies will pay for.