XDC2012: OpenGL futures [LWN.net]

XDC2012: OpenGL futures

Posted Oct 11, 2012 19:55 UTC (Thu) by renox (guest, #23785)
In reply to: XDC2012: OpenGL futures by raven667
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

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

to post comments

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.