[ 
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344251#comment-16344251
 ] 

Michael Jumper commented on GUACAMOLE-168:
------------------------------------------

{quote}
Pardon my ignorant question: isn't a X.Org driver an overkill?
{quote}

It seems a perfect fit, actually. Considering Guacamole as a display mechanism, 
it makes sense to have a driver for a network display (Guacamole) just as you 
would have a driver for a hardware display (graphics card).

{quote}
Won't a compositing WM provide the same features?
{quote}

Unless compositing window managers can be nested, no. This would sacrifice the 
user's ability to use their desktop environment of choice.

> Add support for X.Org
> ---------------------
>
>                 Key: GUACAMOLE-168
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-168
>             Project: Guacamole
>          Issue Type: New Feature
>          Components: guacamole-client, guacamole-server
>            Reporter: Michael Jumper
>            Assignee: Michael Jumper
>            Priority: Major
>
> It's been frequently requested that we add support for a more efficient 
> protocol like NX or X2Go. Though that sounds nice on the surface, and 
> theoretically would allow us to leverage some of Guacamole's nicer 
> protocol-level features, investigating deeper reveals:
> # X2Go *is* NX - it uses the same protocol behind the scenes.
> # NX isn't really a protocol - it is essentially a compressor for X11, and 
> depends on the client having a local X11 server to handle the decompressed 
> result.
> Implementing support for either of these would thus involve implementing 
> support for X11, which is crazy. *However:*
> What about implementing a driver for the X.Org X11 server?
> The X.Org server provides a driver abstraction layer which exposes access to 
> windows (including their hierarchy) and pixmaps, much in the same way the 
> Guacamole protocol provides nestable layers and buffers. If we were to 
> implement a Guacamole driver for X.Org, we would be able to make much greater 
> use Guacamole protocol features like client-side compositing. Operations 
> which are typically expensive in VNC or RDP like window movement suddenly 
> become simple, as they only involve updating the properties of a layer.
> I have an experimental implementation of all this, built upon several other 
> improvements which ended up being required. Work started several years ago, 
> even before Guacamole was accepted into the Apache Incubator, but I think 
> it's finally ready to move forward. I've been using it myself for roughly a 
> month now, and so far so good.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to