XDC2012: OpenGL futures [LWN.net]

XDC2012: OpenGL futures

Posted Oct 11, 2012 19:28 UTC (Thu) by dlang (guest, #313)
In reply to: XDC2012: OpenGL futures by renox
Parent article: XDC2012: OpenGL futures

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

to post comments

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.