[FreeNX-kNX] NX performance issue

[DRC]

> No, no you misunderstood me.
> 
> NX already does GLX -> XPixmap by using the GLX extension of 
> libGL. Which in standard configuration is slow Mesa.
> 
> So I presume you do like you do with turbovnc:
> 
> app -> virtualgl -> HW -> virtualgl -> (as XPixmap) nxagent
> 
> But my proposal is: Just run nxagent under virtualgl so you have:
> 
> app -> nxagent -> virtualgl -> HW -> virtualgl -> nxagent -> 
> remote display ...

I did give that a try, but there are two issues with the approach in
general.  The first is that it forces the application to use an indirect GLX
context (all of the OpenGL commands have to be sent over a local socket to
nxagent -- they can't be sent directly down to the 3D hardware.)  One of the
benefits of using VirtualGL is that, since it redirects the GLX commands
in-process, it can establish a direct rendering context with the 3D
hardware.  Many features of OpenGL don't work with indirect contexts.  When
you use indirect contexts, you're limited to using only the subset of OpenGL
that is supported by the X server (Mesa, in this case.)  The second issue is
that VirtualGL has to monitor a handful of X11 commands from the application
to determine when window resize events have occurred so it can know when to
resize the Pbuffer associated with that window.  So VGL has to be preloaded
into the application process in order to perform this monitoring.

One idea that we're investigating is adding a compressed PutImage()
extension to the NX agent, so VirtualGL could do the image compression
itself and NX could hand off the pre-compressed images to the proxy (via.
NXPutPackedImage().)  Since VGL only does JPEG and raw RGB encoding anyhow,
the NX client already knows how to decode those formats without any
additional modification.  But before I go to the trouble of implementing the
X extension, I wanted to make sure that the system could deliver the
compressed images fast enough -- which is why I'm doing these initial
experiments.

I've added the same TurboJPEG codec to NX that I added to TurboVNC, which
improves the JPEG encoding/decoding speed by about 3X vs. the plain libjpeg
codec.  But in the case of NX, the performance issue described above is
limiting the frame rate to about 30-50% of what TurboVNC can achieve, even
though they're now using the same accelerated codec.  I think that if I can
work past this performance issue, I can make NX perform at least as fast as
TurboVNC.  There's no theoretical reason why it shouldn't.

Darrell