728 lines
37 KiB
XML
728 lines
37 KiB
XML
<?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" [
|
|
<!ENTITY % defs SYSTEM "/xserver/doc/xml/xserver.ent"> %defs;
|
|
]>
|
|
<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>
|
|
<releaseinfo>X Server Version &xserver.version;</releaseinfo>
|
|
<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: -->
|