xserver git update 21/5/2010

1 files changed, 725 insertions, 0 deletions

diff --git a/xorg-server/hw/dmx/doc/scaled.xml b/xorg-server/hw/dmx/doc/scaled.xml
new file mode 100644
index 000000000..575cafd9d
--- /dev/null
+++ b/xorg-server/hw/dmx/doc/scaled.xml
@@ -0,0 +1,725 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>

+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [

+]>

+  <article>

+

+  <articleinfo>

+    <!-- Title information -->

+    <title>Scaled Window Support in DMX</title>

+    <authorgroup>

+      <author><firstname>Kevin E.</firstname><surname>Martin</surname></author>

+      <author><firstname>Rickard E.</firstname><surname>Faith</surname></author>

+    </authorgroup>

+    <pubdate>15 October 2003 (created 19 September 2003)</pubdate>

+    <abstract>

+      <para>

+      This document investigates the possibility of adding scaled window

+      support to the DMX X server, thereby allowing a window or some

+      selected part of the logical DMX area to be displayed using a

+      scaling factor.  For example, this might allow the contents of a

+      window to be magnified for easier viewing.  In particular, scaling

+      for the VNC client is explored.  <emphasis remap="it">Copyright 2003

+        by Red Hat, Inc., Raleigh, North Carolina</emphasis>

+      </para>

+    </abstract>

+  </articleinfo>

+

+      <!-- Begin the document -->

+      <sect1><title>Introduction</title>

+        <sect2><title>DMX</title>

+          <para>

+            The DMX X server (Xdmx) is a proxy server that is designed

+            to allow X servers on multiple machines to be combined into

+            a single multi-headed X server.  Combined with Xinerama,

+            these heads can appear as a single very high-resolution

+            screen.  Typical applications include the creation of a

+            video wall with 16 1280x1024 displays arranged in a

+            rectangle, for a total resolution of of 5120x4096.

+          </para>

+        </sect2>

+        <sect2><title>Problem Statement</title>

+          <para>

+            Applications displayed on a physically large video wall that

+            provides high pixel-resolution may be difficult to see,

+            especially if the application is designed for use on a

+            typical desktop computer with a relatively small display

+            located close to the human operator.  The goal of this paper

+            is to describe and discuss solutions to this problem.

+          </para>

+          <para>

+            The original driving problem for this work is to provide

+            scaling for the <command>vncviewer</command> application when

+            displayed using DMX (VNC scaling is currently available only

+            with the Windows client, and there is no plan to extend that

+            capability to other clients).  While this specific problem

+            will be addressed in this paper, the general solution space

+            will also be explored, since this may lead to a good

+            solution not only for <command>vncviewer</command> but also for

+            other applications.

+          </para>

+        </sect2>

+        <sect2><title>Task</title>

+          <para>

+            For reference, here is the original description of the task

+            this paper addresses:

+            <itemizedlist>

+              <listitem><para>Scaled window support (for VNC)

+                <itemizedlist>

+                  <listitem><para>

+                    Investigate possibility of implementing a "scaled

+                    window" extension:

+                    <itemizedlist>

+                      <listitem><para>

+                        Add XCreateScaledWindow call that could be used

+                        in place of XCreateWindow

+                      </para></listitem>

+                      <listitem><para>

+                        All primitives drawn to scaled window would be

+                        scaled by appropriate (integral?) scaling factor

+                      </para></listitem>

+                    </itemizedlist>

+                  </para></listitem>

+                  <listitem><para>

+                    Alternate approach: special case VNC support

+                  </para></listitem>

+                </itemizedlist>

+              </para></listitem>

+            </itemizedlist>

+          </para>

+        </sect2>

+      </sect1>

+

+      <sect1><title>Previous Work</title>

+        <para>

+          This section reviews relevant previous work.

+        </para>

+        <sect2><title>VNC</title>

+          <sect3><title>Scaling under VNC</title>

+            <para>

+              When using the <command>vncviewer</command> program for Windows, it

+              is possible to specify a scaling factor (as numerator and

+              denominator).  When scaling is in effect, the viewer

+              software uses StretchBlt (instead of BitBlt) to display

+              the pixels for the user.  When this call is made, the

+              viewer already has received all of the pixel information

+              (at full unscaled resolution).

+            </para>

+            <para>

+              The scaling in VNC is primitive.  It does not conserve

+              bandwidth, it does not treat textual information

+              differently (i.e., by using a suitably scaled font), and

+              it does not provide any anti-aliasing other than that

+              provided by the underlying (Windows-only) system library.

+            </para>

+          </sect3>

+        </sect2>

+        <sect2><title>The X Video Extension</title>

+          <para>

+            The X Video Extension is a widely-available extension to the

+            X11 protocol that provides support for streaming video.

+            Integral to this support is the ability to arbitrarily scale

+            the output.  In version 2.2 of the X Video specification,

+            support for scaled still images was provided, using both

+            shared memory and traditional transport.  The API for this

+            support uses calls that are quite similar to XCreateWindow,

+            XPutImage, and XShmPutImage.  Currently, most of the drivers

+            implemented in XFree86 only support data in various YUV

+            formats.  However, several modern video adaptors support RGB

+            as well.

+          </para>

+          <para>

+            Note, though, that the target output for this scaling is an

+            overlay plane -- so X Video provides functionality that is

+            fundamentally different from that provided by the Windows

+            StrechBlt call.

+          </para>

+        </sect2>

+      </sect1>

+

+      <sect1><title>Possible Solutions</title>

+        <para>

+          This section briefly discusses possible solutions, including

+          major advantages and disadvantages from both the

+          implementation and the end-user programmer standpoint.

+        </para>

+        <sect2><title>VNC-like Scaling</title>

+          <sect3><title>Software Scaling</title>

+            <para>

+              The <command>vncviewer</command> application could be modified to

+              provide software scaling.  This is not a general solution,

+              but it does solve one of the goals of this work.

+            </para>

+            <para>

+              A prototype of this solution was implemented and a patch

+              against <filename>vnc-3.3.7-unixsrc</filename> is available in the

+              <filename>dmx/external</filename> directory.  Because of limited time

+              available for this work, all of the edge cases were not

+              considered and the solution works well mainly for integer

+              scaling.

+            </para>

+            <para>

+              Currently, <command>vncviewer</command> writes to the X display

+              with XPutImage, XCopyArea, and XFillRectangle.  All

+              instances of these calls have to be aware of scaling

+              and must round correctly.  In the prototype solution,

+              rounding is incorrect and can cause artifacts.

+            </para>

+            <para>

+              A better solution would be to cache all updates to the

+              desktop image in <command>vncviewer</command> and only send the

+              damaged area to the X display with XPutImage.  This would

+              allow the damaged area to be computed so that rounding

+              errors do not create artifacts.  This method is probably

+              similar to what is used in the Window client.  (The whole

+              VNC suite is being re-written in C++ and the forthcoming

+              version 4 has not been evaluated.)

+            </para>

+          </sect3>

+          <sect3><title>Scaling with the X Video Extension</title>

+            <para>

+              The scaling in the Windows <command>vncviewer</command> application

+              makes use of a scaled blit that is supplied by the

+              underlying system library.  Several video cards currently

+              provide support for a scaled blit, and some X servers

+              (including XFree86) expose this capability to applications

+              via the XvPutImage interface of the X Video Extension.

+              The capability exposed by XvPutImage results in the scaled

+              image being drawn to an overlay plane.  Most video cards

+              also provide support for a scaled blit into the normal

+              output planes, but this is not exposed via XvPutImage.

+            </para>

+            <para>

+              The <command>vncviewer</command> program could be modified to use

+              the X Video Extension to provide scaling under X11 that is

+              similar to the scaling currently provided under Windows.

+              Unfortunately, Xdmx does not currently export the X Video

+              Extension, so this would not provide an immediate solution

+              usable with DMX.

+            </para>

+            <para>

+              A very early-stage proof-of-concept prototype was

+              implemented and a preliminary patch against

+              <filename>vnc-3.3.7-unixsrc</filename> is available in the

+              <filename>dmx/external</filename> directory.  This prototype was

+              implemented to better understand the problems that must be

+              solved to make this solution viable:

+              <itemizedlist>

+                <listitem><para>

+                  As noted under the software scaling section above,

+                  <command>vncviewer</command> writes to the X display with

+                  several different calls.  These calls write to the

+                  normal output planes and are compatible with

+                  XvPutImage, which writes to an overlay plane.  To

+                  eliminate artifacts caused by this problem,

+                  <command>vncviewer</command> should be modified so that a cached

+                  copy of the desktop is available, either as a

+                  client-side image or a server-side off-screen pixmap,

+                  so that XvPutImage would be the only method for

+                  writing to the X display.

+                </para></listitem>

+                <listitem>

+                  <para>

+                    Although several modern graphics adaptors support

+                    hardware scaling using an RGB format (e.g., ATI

+                    Radeon, nVidia, etc.), XFree86 drivers typically

+                    only implement YUV formats.  YUV generally compress

+                    the pixel information in some way.  For example, two

+                    commonly implemented formats, YUY2 and UYVY provide

+                    intensity information for every RGB pixel, but only

+                    provide chroma and luminance information for pairs

+                    of horizontal pixels.  Since VNC uses

+                    pixel-resolution for communicating updates on the

+                    wire, additional artifacts are introduced (because

+                    there may not be enough information from the wire to

+                    update a pair of pixels).

+                  </para>

+                  <para>

+                    Further, the well-known problem with YUV encoding

+                    is even more evident when the image is a desktop

+                    instead of a movie.  For example, consider a

+                    1-pixel-wide vertical window border.  If the border

+                    changes in color but not intensity (e.g., because a

+                    window manager uses color to indicate focus), there

+                    may or may not be a change in the YUY2 image,

+                    depending on the algorithm used for RGB to YUV

+                    conversion and on how the border pixel is ordered in

+                    the pair of pixels used by the algorithm.

+                  </para>

+                  <para>

+                    Many of these artifacts could be eliminated if

+                    <command>vncviewer</command> cached a complete RGB image of

+                    the desktop, and only did the conversion to YUV for

+                    properly aligned areas of damage.  The remaining artifacts

+                    could be eliminated if an RGB format was used with X

+                    Video (which may require the extension of existing

+                    XFree86 drivers to support RGB).

+                  </para>

+	        </listitem>

+                <listitem><para>

+                  Most modern video cards support exactly one overlay

+                  plane that is suitable for use with X Video.

+                  Therefore, only one application can use X Video at any

+                  given time.  This is a severe limitation in a desktop

+                  environment.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+            <sect4><title>Implementing the X Video Extension for DMX</title>

+              <para>

+                The user-level API for X Video is fairly simple, but the

+                underlying support required for the full specification

+                is large.  However, since the API provides a method to

+                query supported capabilities, a usable subset of X

+                Video can be implemented that would support XvPutImage

+                and little else.  This would require support for the

+                following:

+                <itemizedlist>

+                  <listitem><para>

+                    X Video Extension API calls, including the

+                    following:

+                    <itemizedlist>

+                      <listitem><para>XvQueryExtension</para></listitem>

+                      <listitem><para>XvQueryAdaptors</para></listitem>

+                      <listitem><para>XvQueryPortAttributes</para></listitem>

+                      <listitem><para>XvFreeAdaptorInfo</para></listitem>

+                      <listitem><para>XvListImageFormats</para></listitem>

+                      <listitem><para>XvGrabPort</para></listitem>

+                      <listitem><para>XvCreateImage</para></listitem>

+                      <listitem><para>XvPutImage</para></listitem>

+                      <listitem><para>XvShmCreateImage</para></listitem>

+                      <listitem><para>XvShmPutImage</para></listitem>

+                    </itemizedlist>

+                  </para></listitem>

+                  <listitem><para>

+                    Support for querying back-end X Video Extension

+                    capabilities.

+                  </para></listitem>

+                  <listitem><para>

+                    Support for sending the image to the back-ends.

+                    Because X Video requires sending full images, there

+                    may be a trade-off between bandwidth limitations and

+                    additional complexity to divide the image up such

+                    that is scales properly.

+                  </para></listitem>

+                  <listitem><para>

+                    Possible support for a software fall-back.  For

+                    example, if all of the back-ends do not support the X

+                    Video Extension, software scaling can be implemented

+                    such that the image is sent to the back-end with

+                    XPutImage.  This pathway would have poor

+                    performance.

+                  </para></listitem>

+                </itemizedlist>

+              </para>

+            </sect4>

+            <sect4><title>Supporting RGB formats for the X Video Extension</title>

+              <para>

+                Assuming an XFree86 driver already supports the X Video

+                Extension, and assuming the target hardware supports an

+                RGB format, then adding support for that format is

+                relatively simple and straightforward.

+              </para>

+            </sect4>

+          </sect3>

+          <sect3><title>Scaling with an XPutImageScaled Extension</title>

+            <para>

+              Instead of (or in addition to) implementing the X Video

+              Extension in DMX, one obvious solution would be to

+              implement a new extension that provides access to

+              hardware-assisted scaled blits, similar to the StretchBlt

+              call available under Windows.  This call would scale RGB

+              images and would not use the overlay plane (unlike the X

+              Video Extension).

+            </para>

+            <para>

+              This approach has many of the same advantages and

+              disadvantages as the XCopyAreaScaled Extension, discussed

+              in the next section.  Discussion of XPutImageScaled is

+              deferred in favor of XCopyAreaScaled for the following

+              reasons:

+              <itemizedlist>

+                <listitem><para>

+                  XPutImageScaled can be emulated with XCopyAreaScaled

+                  by first using XPutImage to copy the image to an

+                  off-screen pixmap, and then calling XCopyAreaScaled

+                  between that off-screen pixmap and the target

+                  drawable.

+                </para></listitem>

+                <listitem><para>

+                  Since XCopyAreaScaled would copy between two areas of

+                  on-screen or off-screen memory, it has additional uses

+                  and can be viewed as efficiently providing a superset

+                  of XPutImageScaled functionality.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+          </sect3>

+          <sect3><title>Scaling with an XCopyAreaScaled Extension</title>

+            <para>

+              As noted in the previous section, because XCopyAreaScaled

+              provides a superset of the functionality provided by

+              XPutImageScaled, we will consider this extension instead.

+            </para>

+            <para>

+              First, XCopyAreaScaled would provide for RGB scaling

+              between pixmaps (i.e., on-screen or off-screen areas of

+              memory that reside on the video card).  Unlike the X Video

+              Extension, which writes into an overlay plane,

+              XCopyAreaScaled would write into the non-overlay areas of

+              the screen.  Key points to consider are as follows:

+              <itemizedlist>

+                <listitem><para>

+                  Because different planes are involved, the two scaling

+                  operations are usually implemented in hardware

+                  differently, so an XCopyAreaScaled extension could be

+                  added in a manner that would neither conflict with nor

+                  interact with the X Video extension in any way.

+                </para></listitem>

+                <listitem><para>

+                  The XCopyAreaScaled extension provides new

+                  functionality that the X Video Extension does not

+                  provide.  Based on anecdotal feedback, we believe that

+                  many people outside the DMX and VNC communities would

+                  be excited about this extension.

+                </para></listitem>

+                <listitem><para>

+                  The main drawback to this extension is that it is new

+                  and needs to be implemented at the driver level in

+                  XFree86 for each video card to be supported.  At the

+                  present time, it is more likely that the X Video

+                  Extension will be implemented for a particular piece

+                  hardware because the X Video extension has multimedia

+                  uses.  However, over time, we would expect the

+                  XCopyAreaScaled extension to be implemented along with

+                  the X Video extension, especially if it becomes

+                  popular.

+                </para></listitem>

+                <listitem><para>

+                  Another drawback is that not all modern cards provide

+                  support for a simple scaled blit operation.  However,

+                  these cards usually do provide a 3D pipeline which

+                  could be used to provide this functionality in a

+                  manner that is transparent to the client application

+                  that is using the XCopyAreaScaled extension.  However,

+                  this implementation pathway would make this extension

+                  somewhat more difficult to implement on certain cards.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+          </sect3>

+          <sect3><title>Scaling with OpenGL</title>

+            <para>

+              Another general solution to the scaling problem is to use

+              the texture scaling found in all 3D hardware.  This

+              ability is already exposed through OpenGL and can be

+              exploited by clients without X server modification (i.e.,

+              other than the ability to support OpenGL).  An application

+              using OpenGL would transmit the non-scaled image to the X

+              server as a texture, and would then display a single

+              non-transformed rect using that texture.  This also works

+              around the single overlay problem with the X Video

+              Extension as well as the need to implement additional

+              scaled primitive extensions.

+            </para>

+            <para>

+              The downside is that most OpenGL implementations require

+              power of 2 texture sizes and this can be very wasteful of

+              memory if, for example, the application needs to scale a

+              1025x1025 image, which would require a 2048x2048 texture

+              area (even a 640x480 image would require a 1024x512

+              texture).  Another downside is that some OpenGL

+              implementations have a limited about of texture memory and

+              cannot handle textures that are very large.  For example,

+              they might limit the texture size to 1024x1024.

+            </para>

+          </sect3>

+        </sect2>

+        <sect2><title>Application-transparent Scaling for DMX

+          </title><sect3><title>Back-end Scaling Without Disconnect/Reconnect</title>

+            <para>

+              VNC does scaling on the client side (in the

+              <command>vncviewer</command> application).  Implementing a similar

+              solution for DMX would require support in the back-end X

+              servers and, therefore, is not a general solution.

+            </para>

+            <para>

+              XFree86 already implements some support for "scaling" that

+              could be used with DMX: if, in the XF86Config file,

+              multiple Modes are listed in the Display Subsection of the

+              Screen Section, then pressing Ctrl-Alt-Plus and

+              Ctrl-Alt-Minus can be used to iterate through the listed

+              modes.  The display dimensions will change to the

+              dimensions in the Modes line, but the logical dimensions

+              of the X server (i.e., the dimensions that Xdmx knows

+              about) will not change.

+            </para>

+            <para>

+              Further, the dimensions of the XFree86 display are under

+              software control (via the XFree86-VidModeExtension), so

+              the Xdmx server could change the screen dimensions on a

+              per-display basis, thereby scaling the information on part

+              of that display.

+            </para>

+            <para>

+              However, this scaling appears to have limited use.  For

+              example, assume a 4 by 4 display wall consisting of 16

+              1280x1024 displays.  If all of the back-end servers were

+              simultaneously configured to display 640x480, the left

+              hand corner of each display would be magnified, but the

+              composite result would be unreadable.  Magnifying one

+              display at a time could be usable, but could have limited

+              utility, since the result would still be no larger than a

+              single display.

+            </para>

+          </sect3>

+          <sect3><title>Back-end Scaling With Disconnect/Reconnect</title>

+            <para>

+              Disconnect and reconnect features are not currently

+              supported in DMX, but are scheduled to be implemented in

+              the future.  These features, combined with the

+              XFree86-VidModeExtension Extension, would allow an

+              application to do the following:

+              <itemizedlist>

+                <listitem><para>

+                  Disconnect a specific back-end server (via the DMX

+                  Extension),

+                </para></listitem>

+                <listitem><para>

+                  reconfigure the XFree86 back-end server resolution,

+                  and

+                </para></listitem>

+                <listitem><para>

+                  reconnect the back-end server to DMX -- at a new

+                  origin with the new screen resolution.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+            <para>

+              For example, consider a display wall consisting of 16

+              1280x1024 displays with a total resolution of 5120x4096.

+              All of the screens could be disconnected, repositioned,

+              and reconnected each at a resolution of 640x480.  The

+              total resolution of the display wall would be 2560x1920,

+              allowing a view of a selected area approximately

+              one-fourth of the size of the DMX display.  This change

+              would be completely application independent (except,

+              perhaps, for a DMX-aware window manager).  When work at

+              the increased resolution was completed, the back-end

+              servers could be disconnected, reconfigured, and

+              reconnected for the original 5120x4096 view.

+            </para>

+            <para>

+              Support for this type of scaling can be implemented in a

+              DMX-aware X11 client assuming the DMX server support

+              arbitrary disconnect and reconnect semantics.  Because

+              this application cannot be written before

+              disconnect/reconnect is implemented, this solution will

+              not be discussed further in this paper.

+            </para>

+          </sect3>

+          <sect3><title>Server-side Scaling</title>

+            <para>

+              In earlier versions of DMX, a frame buffer was maintained

+              on the server side, and XPutImage was used to move the

+              information from the server to the client (similar to some

+              early VNC implementations).  The use of a server-side

+              frame buffer would allow the server to do scaling, but is

+              not a recommended solution because of overall performance

+              issues and server-side memory issues (i.e., the frame

+              buffer would be very large for large display walls).

+            </para>

+            <para>

+              Exploration of this path is not recommended.

+            </para>

+          </sect3>

+        </sect2>

+        <sect2><title>XCreateScaledWindow API</title>

+          <para>

+            The implementation of X Video Extension in DMX, and the use

+            of XvPutImage by applications requiring scaling requires

+            significant changes in DMX Further, XvPutImage is,

+            essentially a scaled blit, and it is only useful for

+            applications which are already using (or can be modified to

+            use) XPutImage.  Therefore, a more general API will be

+            discussed as another possibility.

+          </para>

+          <para>

+            X applications typically create windows with the

+            XCreateWindow call.  A new extension could provide an

+            XCreateScaledWindow call that could be used in place of the

+            XCreateWindow call and be otherwise transparent to the

+            application.  This would allow applications, even those that

+            do not depend on XPutImage, to take advantage of window

+            scaling.  In this section we describe how the call would

+            work, what transparency it provides, and how to solve the

+            potential problems that transparency creates.

+          </para>

+          <sect3><title>XCreateWindow</title>

+            <para>

+              The XCreateWindow call takes width and height as

+              parameters.  An XCreateScaledWindow call could take all

+              the same parameters, with the addition of a scaling factor.

+            </para>

+          </sect3>

+          <sect3><title>XSetWindowAttributes</title>

+            <para>

+              An X11 window has several attributes that would have to be

+              scaled:

+              <itemizedlist>

+                <listitem><para>Background and border pixmaps</para></listitem>

+                <listitem><para>Border width</para></listitem>

+                <listitem><para>Cursor</para></listitem>

+              </itemizedlist>

+            </para>

+          </sect3>

+          <sect3><title>XGetWindowAttributes, XGetGeometry</title>

+            <para>

+              For transparency, calls that query the window attributes

+              should return unscaled information.  This suggests that

+              all unscaled pixmaps and window attributes should be

+              cached.

+            </para>

+            <para>

+              Unfortunately, a window manager requires the scaled

+              geometry to properly decorate the window.  The X server

+              can probably determine which client is acting as the

+              window manager (e.g., because that client will select

+              events that are used exclusively by the window manager).

+              However, other Scaled Window Extension aware clients may

+              also need to determine the scaled geometry.  Therefore, at

+              least two additional extension calls should be

+              implemented: XGetScaledWindowAttributes and

+              XGetScaledGeometry.

+            </para>

+          </sect3>

+          <sect3><title>Popup and Child window positions</title>

+            <para>

+              Some applications may position popup and child windows

+              based on an unscaled notion of the main window geometry.

+              In this case, additional modifications to the client would

+              be required.

+            </para>

+          </sect3>

+          <sect3><title>Events</title>

+            <para>

+              Most events (e.g., for mouse motion) return information

+              about the coordinates at which the even occurred.  These

+              coordinates would have to be modified so that unscaled

+              values were presented to the client.

+            </para>

+          </sect3>

+          <sect3><title>Implementation</title>

+            <para>

+              There are many implementation issues, some of which are

+              similar to the issues involved in implementing the X Video

+              Extension for DMX.  The window contents must be scaled,

+              either by performing all operations to a frame buffer and

+              then writing the image to the display (perhaps using

+              hardware scaling support), or by modifying all of the

+              various drawing operations to perform scaling.  Because of

+              the complexity involved, the frame buffer option is

+              recommended.

+            </para>

+          </sect3>

+        </sect2>

+      </sect1>

+

+      <sect1><title>Conclusion and Recommendations

+        </title><para>

+          We recommend a three phase implementation strategy, based on

+          how an application could be written to take advantage of

+          scaling:

+          <orderedlist>

+            <listitem>

+              <para>

+                The XCopyAreaScaled extension should be implemented, since

+                this is the ideal solution for applications like VNC, and

+                since making use of this extension will require minimal

+                changes to applications that already use XPutImage or

+                XCopyArea.

+              </para>

+              <para>

+                The initial implementation work would include the design

+                of the X protocol extension, writing this up in the

+                usual format for extension documentation, implementation

+                of the protocol transport pieces in XFree86,

+                implementation of a software fall-back in XFree86 and

+                DMX, one example hardware implementation for XFree86,

+                and implementation of support for this extension in DMX.

+              </para>

+              <para>

+                We suggest implementing the extension first on the ATI

+                Radeon cards.  However, since these cards do not provide

+                a 2D scaled blit primitive, the implementation would

+                have to make use of the 3D texture engine to emulate a

+                scaled blit.  This is recommended, since other modern

+                graphics cards also do not provide a simple 2D scaled

+                blit operation and an example of the more difficult

+                implementation pathway would be helpful to others.

+              </para>

+            </listitem>

+            <listitem>

+              <para>

+                Until XCopyAreaScaled is widely supported, applications

+                that require scaling will have to fall back to another

+                scaling method.  We suggest OpenGL as the first fall-back

+                method because it is widely available and supported by

+                DMX.

+              </para>

+              <para>

+                A project centered around OpenGL-based scaling would

+                implement this scaling in VNC as an example.  This work

+                would include re-writing the <command>vncviewer</command>

+                rendering engine to cache a master copy of the desktop

+                image for all operations.

+              </para>

+            </listitem>

+            <listitem>

+              <para>

+                Since OpenGL is not implemented everywhere, and may not

+                provide hardware-assisted performance in every

+                implementation, an application that requires scaling

+                should also fall back to using the X Video Extension.

+              </para>

+              <para>

+                This project would add support for the X Video Extension

+                to DMX and would add support to VNC to take advantage of

+                this extension without introducing artifacts.  This

+                would require modifying the <command>vncviewer</command> rendering

+                engine to cache a master copy of the desktop image for

+                all operations.  This project should also add support

+                for the RGB format to at least one XFree86 driver (e.g.,

+                ATI Radeon).

+              </para>

+              <para>

+                The X Video Extension is one of the few popular

+                extensions that DMX does not support.  We recommend

+                implementing the X Video Extension even if scaling is

+                the specific goal of that work.

+              </para>

+            </listitem>

+          </orderedlist>

+        </para>

+        <para>

+          We do <emphasis>not</emphasis> recommend implementation of the

+          XCreateScaledWindow extension because of the complexity

+          involved.  We do <emphasis>not</emphasis> recommend implementation of the

+          XPutImageScaled extension because it requires the same amount

+          of work as the XCopyAreaScaled extension, but provides less

+          functionality.  Further, server-side scaling with a large

+          frame buffer is <emphasis>not</emphasis> recommended because of the

+          performance implications.

+        </para>

+        <para>

+          The back-end scaling, especially with disconnect/reconnect

+          support should be explored in the future after

+          disconnect/reconnect is implemented, but not at the present

+          time.

+        </para>

+      </sect1>

+

+  </article>

+  <!-- Local Variables: -->

+  <!-- fill-column: 72  -->

+  <!-- End:             -->