XDC2012: OpenGL futures [LWN.net]

XDC2012: OpenGL futures

Posted Oct 11, 2012 12:09 UTC (Thu) by renox (guest, #23785)
In reply to: XDC2012: OpenGL futures by mjg59
Parent article: XDC2012: OpenGL futures

No good reason? Reducing the bandwith used in many common situations (when you don't run a game or a video) is a *very good* reason.
That said, you do have a point that at some point the bandwith used by the rendering commands(and textures) could be higher than sending a bitmap.
So the "ideal" (but complicated solution) would be to send the rendering commands&texture when their size is smaller that the size of a screen bitmap otherwise send the bitmap.
Of course, this is made more complicated that you can send the diff between two bitmaps or/and compress the bitmap, but this has a latency cost..

to post comments

XDC2012: OpenGL futures

Posted Oct 11, 2012 15:24 UTC (Thu) by raven667 (guest, #5198) [Link] (8 responses)

My understanding is that sending drawing commands has a major latency cost. The way that was fixed in the X protocol was to run a proxy or local renderer where the client app runs and then ship bitmaps, like NX and xpra. You can still do smart things with caches, icons, prerendered font glyphs, offscreen scroll areas, prerendered buttons, etc. should be cachable at the display side.

XDC2012: OpenGL futures

Posted Oct 11, 2012 15:46 UTC (Thu) by renox (guest, #23785) [Link] (7 responses)

> My understanding is that sending drawing commands has a major latency cost

Huh? Only if you want to re-read the output of these commands (a bad thing to do anyway) or if you do 'cmd1; wait for status; cmd2; wait for status' otherwise why should there be a difference?

> The way that was fixed in the X protocol was to run a proxy or local renderer where the client app runs and then ship bitmaps, like NX and xpra.

Are you sure that this is what NX do?

> You can still do smart things with caches, icons, prerendered font glyphs, offscreen scroll areas, prerendered buttons, etc. should be cachable at the display side.

For X, yes, for Wayland I don't think so as it has no server side drawing commands (short of sending buffer without knowing where they will be displayed).

XDC2012: OpenGL futures

Posted Oct 11, 2012 16:16 UTC (Thu) by raven667 (guest, #5198) [Link] (4 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 (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.

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.

XDC2012: OpenGL futures

Posted Oct 11, 2012 19:28 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

my understanding of NX isn't that it does any local rendering, but that it instead shortcuts the roundtrips to the server by intercepting calls and returning the values directly.

Due to it's history, X can't assume much about what's on the other end, however in modern implementations there really is a lot that is always going to be available. With pure X there is a lot of chatter of the type 'do you support feature Y' that can just be short circuited.

In addition, there were drawing primitives that were synchronous (cmd1l result cmd2 result...) because systems were so short of resources that any of the commands could fail due to running out of them. Nowadays the resources are so plentiful that this is almost always a waste of time, so something like NX can return a result immediately (unless the system on the other side has said that it's getting low on resources)

you see the same type of thing in WAN accelerators for windows networking protocols. In both cases the real limit isn't bandwith, it's a chatty protocol that works well on low-latency systems, but can suffer badly when on a high latency system

XDC2012: OpenGL futures

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

> my understanding of NX isn't that it does any local rendering, but that it instead shortcuts the roundtrips to the server by intercepting calls and returning the values directly.

I think that's true for older apps that use the core X protocol, xman, xterm, xeyes, xclock are accelerated this way. For newer apps using newer toolkits like Gtk2/3, Qt, etc. I think there is a lot more bitmap shuffling because the client app toolkit depends on being able to do compositing, blending, antialiasing, etc. and shipping the result to the display.