[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347936#comment-16347936
]
Berserker Troll commented on GUACAMOLE-168:
-------------------------------------------
{quote}Won't a compositing WM provide the same features?{quote}
I think I can answer my own question.
The X Composite Extension allows one to redirect window rendering to off-screen
storage.
The X DAMAGE Extension allows one to get information about DAMAGEd (by
painting) regions.
Compositing managers use either the X Rendering Extension (slow) or OpenGL
(fast) to (re)draw the windows, add shadows, add transparency etc.
The off-screen window pixmaps are stored on the server and XRENDER/OpenGL has
no problem accessing them. But the compositing manager doesn't have direct
access to these pixmaps. One may think about using MIT-SHM extension, but, if I
understand it correctly, a driver has to support this extension and the dummy
driver (what else would you use with remote rendering?) doesn't support MIT-SHM.
> 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)
