Today, Shawn Bass, Ruben Spruijt, and Benny Tritsch unveiled TeamRGE.com, a site they created to share their ideas about remote graphics for virtual desktops and applications. RGE stands for Remoting Graphics Experts, and if you’re at all familiar with the work they’ve done over the last several years with regards to remote graphics, you’ll understand how that term is an understatement. Nobody has spent more time testing, benchmarking, compiling results, and presenting about remote graphics than this group of guys!
TeamRGE.com is being launched in order to share an updated version of the free white paper that Ruben Spruijt shared with us last year. Since everyone has different jobs this year, the team decided to create an independent web site to further the discussion and share the results of their ongoing work.
The 93-page white paper is a complete look into the usage of 3D graphics with remote desktops and applications. No stone is left unturned, but you don’t have to be a “graphics person” to understand what they’re talking about. TeamRGE has done a fantastic job of presenting loads of data while telling a story that will make sense to anyone. They start at the beginning, explaining the different ways graphics are handled based on the platform you’re using:
From there, they talk about the remoting capabilities of different graphics systems (e.g. GDI, DirectX, OpenGL, Flash, Silverlight, HTML5, CUDA, and more) and how they work (host-side versus client-side). There’s something for everyone to learn here–check out this excerpt on GDI Remoting:
Graphics Device Interface (GDI) is an application programming interface (API) that was developed by Microsoft in the 80’s and 90’s of the last century. It is responsible for defining and rendering graphical objects on Microsoft Windows. GDI rendering or rasterization is the task of taking an image described through vector shapes or primitives and converting it into a raster image consisting of pixels or dots for output on a GDI-compatible video display or printer. Such a rasterized image can also be stored in a standard bitmap file format.
Typical GDI primitives are lines, rectangles, ellipses, arcs, Bezier splines, filled areas, bitmaps and fonts. A significant capability of GDI is its indirect method of accessing the underlying hardware by drawing on a Device Context (DC). A DC represents an abstraction layer that can be mapped to multiple physical target devices, such as screens and printers. A GDI applications sends its graphics output to the DC and then the Windows system sends the DC content to the target device.
It is important to note that GDI was designed in such a way that it can be hardware accelerated in a graphics card. Every modern PC graphics card supports the full GDI function set in hardware. During the Windows initialization phase, GDI hardware acceleration is registered in the system, significantly reducing CPU load generated by graphics output during system runtime.
In GDI there is no mechanism of synchronizing the DC with the graphics card frame buffer. As a result, GDI is not good at animating graphics primitives. There is no built-in method for double buffering animated output. In addition to that, GDI is a 2D graphics system, so it lacks the capability of rendering 3D primitives. The only 3D capability of GDI is the z-order of a window indicating its position in a stack of potentially overlapping windows. A window in the z-order list overlaps all other windows that are closer to the bottom of the z-order.
Most traditional Windows applications are built on top of GDI. The application windows and dialog boxes consist of basic GDI window objects, such as borders, title bars, captions, control boxes, scroll bars, menu bars and icons. These window objects are built of even more elementary GDI primitives, creating a hierarchical system of GDI primitives and window objects. A message pipeline allows an application to send graphical output to the client area of one of its windows or dialog boxes.
When Windows XP was introduced, GDI was extended by the GDI+ subsystem. GDI+ added more 2D graphics features and the support of modern graphics file formats. The Microsoft .NET Framework includes a managed GDI+ interface through the System. Drawing namespace. Substantial portions of GDI+ are not hardware accelerated.
The first designs of the Microsoft Remote Desktop Protocol (RDP) adopted many concepts of GDI and GDI+. The general idea was that remoting client and host negotiated their common set of GDI capabilities during connection, allowing for an advanced level of client side rendering. If the resulting session properties did not include the support of GDI elements like bitmaps, pointers, fonts, brushes, glyphs and standard windows, the communication fell back to pixels. This was referred to as “screen scraping”, where all pixels of a rendered desktop were “scraped” from the host video memory and then transmitted to the client.
Today, both GDI and GDI+ are not as relevant as they used to be in the Windows XP times. They were replaced by more modern graphics formats such as DirectX and Windows Presentation Foundation. As GDI falls in popularity, so does the relevance of client side rendering.
After that, they move on to explaining in great detail how the different virtual desktop and application vendor solutions work (e.g. Citrix XenApp and XenDesktop, Fra.me, Microsoft RDS, VMware Horizon, and others), from both the protocol and the system design standpoints.
From there they move on to APU and GPU technology, starting with an introduction before taking you on a deep dive into the capabilities that AMD, Intel, and NVIDIA have and how their specific offerings fit into your virtualization and remote desktop environments. They even go over cloud services that leverage GPU instances such as Amazon EC2 and Microsoft Azure before talking about “Enabling Technologies” like HP RGS, Teradici PCoIP, and monitoring tools.
What makes this paper so awesome is that the guys at TeamRGE have done all the work for you. They’ve researched all the products and measured their performance both subjectively (to get the user experience) and objectively (to get the resource implications). Anyone that’s building or managing a desktop virtualization environment needs to read this. It’s 93 pages of information that would take you years to collect on your own.
To download the FREE white paper or participate in the conversation, visit TeamRGE.com.