Wednesday, October 28, 2009

gnome-shell Over Remote Display

It's been my pleasure to see gnome-shell mature over the last few months. I was in Boston last year when it started on the white boards, very cool stuff.

I have been wanting to experimentally get gnome-shell and Zeitgeist into the hands of 'regular users' for feedback. I built a Fedora Core 12 server, and got gnome-shell running. I then tested it over remote display. Clutter failed in my first test because it doesn't yet support 16 bit color depth. I bumped the thin client up to 24 bit color and tried again. I built a page on Live with my results and it's here

The visuals are not working correctly, but once it's up and running performance seems fine.
I don't have the expertise to fix this type of low level bug in clutter, but if anyone with the knowledge wants to find me on the IRC, I will gladly test patches and ideas.



We aren't the only people running thin clients, and one hates to not have this major feature available for enterprise customers that want to run GNOME 3.

2 comments:

Robert Bragg said...

Supporting 16bpp render targets shouldn't be a huge amount of effort; we have had this working in the past for some of Clutter's EGL backends since it's an important optimization for embedded devices with limited memory bandwidth. I think the real problem for you will sadly be the archaic GLX wire protocol.

The GLX encoding spec[1] used to serialize OpenGL requests hasn't been updated since 1999 and is missing important OpenGL features including Vertex Buffers. Although we have abstracted VBOs in the Cogl layer under Clutter so that we can fallback to immediate mode rendering when VBOs are missing; this and other fallbacks may badly affect your performance.

Asside from missing encodings, some of the existing encodings also need replacing. For example glTexImage2D with a NULL data pointer (which asks OpenGL to allocate a texture with a given size without any initial data) actually requires dummy data to be sent over the wire, which is ridiculous. This was fixed for glTexImage3D encoding, but a new command is needed to fix it for glTexImage2D. We do this in Clutter and there's a related bug with more details: http://bugzilla.o-hand.com/show_bug.cgi?id=1240

If people are interested in using Clutter based applications remotely then I think it would be great if someone could really persue this problem. The silly thing is that features like Vertex Buffers actually suite the remote server model very nicely (i.e. the idea of loading your geometry onto the GPU - over the wire - and using simpler commands to draw from your server side vertex data)

One think to be aware of is that the spec is owned by Khronos[2] so in the end we'll need to figure out if they'll accept changes or perhaps give up ownership given they apparently don't have an interest in maintaining it themselves. I'd suggest ignoring this aspect until something is implemented and working though.

[1] http://www.opengl.org/documentation/specs/glx/encode1.3.ps
[2] http://www.khronos.org/

Anonymous said...

Can anyone recommend the top Endpoint Security software for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: N-able N-central server management
? What is your best take in cost vs performance among those three? I need a good advice please... Thanks in advance!