XDC2012: OpenGL futures [LWN.net]

XDC2012: OpenGL futures

Posted Oct 11, 2012 16:16 UTC (Thu) by raven667 (guest, #5198)
In reply to: XDC2012: OpenGL futures by renox
Parent article: XDC2012: OpenGL futures

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 (not xterm, xclock, xman and xeyes) which can lead to a perverse result where all the drawing commands and bitmaps are sent from the app to the display, rendered, then shipped back to the app. If you want a simple rendering model for remote apps then HTML/CSS/JS seems a better bet.

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.

Wayland is just the protocol to the output buffer on the display, you have free reign on what the remoting protocol looks like. You can make a virtual wayland framebuffer and send that or do something toolkit specific or use X or make some new standard protocol that the toolkits can output to.

to post comments

XDC2012: OpenGL futures

Posted Oct 11, 2012 19:55 UTC (Thu) by renox (guest, #23785) [Link] (3 responses)

>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..

>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..

>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..

XDC2012: OpenGL futures

Posted Oct 11, 2012 20:20 UTC (Thu) by raven667 (guest, #5198) [Link] (2 responses)

>>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.

XDC2012: OpenGL futures

Posted Oct 12, 2012 7:28 UTC (Fri) by renox (guest, #23785) [Link] (1 responses)

> 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.

This would be a regression compared to X.
If an application needs to do local rendering then it can renders its images however it likes: I don't see the need to blend this requirement into the display protocol.

As for WebGL, it is a toy until it can be made reasonably secure.

XDC2012: OpenGL futures

Posted Oct 12, 2012 15:44 UTC (Fri) by khim (subscriber, #9252) [Link]

As for WebGL, it is a toy until it can be made reasonably secure.

It's the other way around: nobody will bother to make it reasonably secure till it's more than a toy. You may claim that it's totally wrong way to build "anything secure", but this is how things are done in real world.