>>You may think its a "bad thing" for the app to have access to it's rendered image but this is often required on modern apps
>Then they should do their own rendering locally, not require that the display protocol is limited to local image rendering..
They can be two different protocols, the protocol for talking to a local display doesn't have to be the same protocol for remoting they are different use cases with different requirements.
>>If you want a simple rendering model for remote apps then HTML/CSS/JS seems a better bet.
>That's a totally different use case: the resources used are not comparable..
Those cases are blending together more and more. There are three ways to deploy an app, native local, native using a remote display protocol or HTML/CSS/JS and the HTML app deployment method is becoming the norm, local apps are becoming niche and remote display apps are a tiny case compared to the other two.
>>Actually think about the rendering needs of a modern web browser, what you can do from CSS and WebGL and what that requires of the underlying graphics subsystem.
>WebGL is the same use case as games..
Not exactly it's the underlying accelerated GUI toolkit functions needed by your standard HTML5 Canvas or WebGL app. You have text and images and 3d objects all composited and styled together, not just an empty buffer that the application manages like a game. Unless your point is that a web browser should just be given a GLES framebuffer and implement it's own GUI toolkit internally to support modern features.