1<?xml version="1.0" encoding="ISO-8859-1"?> 2<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" 3 "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ 4 <!ENTITY % defs SYSTEM "/xserver/doc/xml/xserver.ent"> %defs; 5]> 6 <article> 7 8 <articleinfo> 9 <!-- Title information --> 10 <title>Scaled Window Support in DMX</title> 11 <authorgroup> 12 <author><firstname>Kevin E.</firstname><surname>Martin</surname></author> 13 <author><firstname>Rickard E.</firstname><surname>Faith</surname></author> 14 </authorgroup> 15 <pubdate>15 October 2003 (created 19 September 2003)</pubdate> 16 <releaseinfo>X Server Version &xserver.version;</releaseinfo> 17 <abstract> 18 <para> 19 This document investigates the possibility of adding scaled window 20 support to the DMX X server, thereby allowing a window or some 21 selected part of the logical DMX area to be displayed using a 22 scaling factor. For example, this might allow the contents of a 23 window to be magnified for easier viewing. In particular, scaling 24 for the VNC client is explored. <emphasis remap="it">Copyright 2003 25 by Red Hat, Inc., Raleigh, North Carolina</emphasis> 26 </para> 27 </abstract> 28 </articleinfo> 29 30 <!-- Begin the document --> 31 <sect1><title>Introduction</title> 32 <sect2><title>DMX</title> 33 <para> 34 The DMX X server (Xdmx) is a proxy server that is designed 35 to allow X servers on multiple machines to be combined into 36 a single multi-headed X server. Combined with Xinerama, 37 these heads can appear as a single very high-resolution 38 screen. Typical applications include the creation of a 39 video wall with 16 1280x1024 displays arranged in a 40 rectangle, for a total resolution of of 5120x4096. 41 </para> 42 </sect2> 43 <sect2><title>Problem Statement</title> 44 <para> 45 Applications displayed on a physically large video wall that 46 provides high pixel-resolution may be difficult to see, 47 especially if the application is designed for use on a 48 typical desktop computer with a relatively small display 49 located close to the human operator. The goal of this paper 50 is to describe and discuss solutions to this problem. 51 </para> 52 <para> 53 The original driving problem for this work is to provide 54 scaling for the <command>vncviewer</command> application when 55 displayed using DMX (VNC scaling is currently available only 56 with the Windows client, and there is no plan to extend that 57 capability to other clients). While this specific problem 58 will be addressed in this paper, the general solution space 59 will also be explored, since this may lead to a good 60 solution not only for <command>vncviewer</command> but also for 61 other applications. 62 </para> 63 </sect2> 64 <sect2><title>Task</title> 65 <para> 66 For reference, here is the original description of the task 67 this paper addresses: 68 <itemizedlist> 69 <listitem><para>Scaled window support (for VNC) 70 <itemizedlist> 71 <listitem><para> 72 Investigate possibility of implementing a "scaled 73 window" extension: 74 <itemizedlist> 75 <listitem><para> 76 Add XCreateScaledWindow call that could be used 77 in place of XCreateWindow 78 </para></listitem> 79 <listitem><para> 80 All primitives drawn to scaled window would be 81 scaled by appropriate (integral?) scaling factor 82 </para></listitem> 83 </itemizedlist> 84 </para></listitem> 85 <listitem><para> 86 Alternate approach: special case VNC support 87 </para></listitem> 88 </itemizedlist> 89 </para></listitem> 90 </itemizedlist> 91 </para> 92 </sect2> 93 </sect1> 94 95 <sect1><title>Previous Work</title> 96 <para> 97 This section reviews relevant previous work. 98 </para> 99 <sect2><title>VNC</title> 100 <sect3><title>Scaling under VNC</title> 101 <para> 102 When using the <command>vncviewer</command> program for Windows, it 103 is possible to specify a scaling factor (as numerator and 104 denominator). When scaling is in effect, the viewer 105 software uses StretchBlt (instead of BitBlt) to display 106 the pixels for the user. When this call is made, the 107 viewer already has received all of the pixel information 108 (at full unscaled resolution). 109 </para> 110 <para> 111 The scaling in VNC is primitive. It does not conserve 112 bandwidth, it does not treat textual information 113 differently (i.e., by using a suitably scaled font), and 114 it does not provide any anti-aliasing other than that 115 provided by the underlying (Windows-only) system library. 116 </para> 117 </sect3> 118 </sect2> 119 <sect2><title>The X Video Extension</title> 120 <para> 121 The X Video Extension is a widely-available extension to the 122 X11 protocol that provides support for streaming video. 123 Integral to this support is the ability to arbitrarily scale 124 the output. In version 2.2 of the X Video specification, 125 support for scaled still images was provided, using both 126 shared memory and traditional transport. The API for this 127 support uses calls that are quite similar to XCreateWindow, 128 XPutImage, and XShmPutImage. Currently, most of the drivers 129 implemented in XFree86 only support data in various YUV 130 formats. However, several modern video adaptors support RGB 131 as well. 132 </para> 133 <para> 134 Note, though, that the target output for this scaling is an 135 overlay plane -- so X Video provides functionality that is 136 fundamentally different from that provided by the Windows 137 StrechBlt call. 138 </para> 139 </sect2> 140 </sect1> 141 142 <sect1><title>Possible Solutions</title> 143 <para> 144 This section briefly discusses possible solutions, including 145 major advantages and disadvantages from both the 146 implementation and the end-user programmer standpoint. 147 </para> 148 <sect2><title>VNC-like Scaling</title> 149 <sect3><title>Software Scaling</title> 150 <para> 151 The <command>vncviewer</command> application could be modified to 152 provide software scaling. This is not a general solution, 153 but it does solve one of the goals of this work. 154 </para> 155 <para> 156 A prototype of this solution was implemented and a patch 157 against <filename>vnc-3.3.7-unixsrc</filename> is available in the 158 <filename>dmx/external</filename> directory. Because of limited time 159 available for this work, all of the edge cases were not 160 considered and the solution works well mainly for integer 161 scaling. 162 </para> 163 <para> 164 Currently, <command>vncviewer</command> writes to the X display 165 with XPutImage, XCopyArea, and XFillRectangle. All 166 instances of these calls have to be aware of scaling 167 and must round correctly. In the prototype solution, 168 rounding is incorrect and can cause artifacts. 169 </para> 170 <para> 171 A better solution would be to cache all updates to the 172 desktop image in <command>vncviewer</command> and only send the 173 damaged area to the X display with XPutImage. This would 174 allow the damaged area to be computed so that rounding 175 errors do not create artifacts. This method is probably 176 similar to what is used in the Window client. (The whole 177 VNC suite is being re-written in C++ and the forthcoming 178 version 4 has not been evaluated.) 179 </para> 180 </sect3> 181 <sect3><title>Scaling with the X Video Extension</title> 182 <para> 183 The scaling in the Windows <command>vncviewer</command> application 184 makes use of a scaled blit that is supplied by the 185 underlying system library. Several video cards currently 186 provide support for a scaled blit, and some X servers 187 (including XFree86) expose this capability to applications 188 via the XvPutImage interface of the X Video Extension. 189 The capability exposed by XvPutImage results in the scaled 190 image being drawn to an overlay plane. Most video cards 191 also provide support for a scaled blit into the normal 192 output planes, but this is not exposed via XvPutImage. 193 </para> 194 <para> 195 The <command>vncviewer</command> program could be modified to use 196 the X Video Extension to provide scaling under X11 that is 197 similar to the scaling currently provided under Windows. 198 Unfortunately, Xdmx does not currently export the X Video 199 Extension, so this would not provide an immediate solution 200 usable with DMX. 201 </para> 202 <para> 203 A very early-stage proof-of-concept prototype was 204 implemented and a preliminary patch against 205 <filename>vnc-3.3.7-unixsrc</filename> is available in the 206 <filename>dmx/external</filename> directory. This prototype was 207 implemented to better understand the problems that must be 208 solved to make this solution viable: 209 <itemizedlist> 210 <listitem><para> 211 As noted under the software scaling section above, 212 <command>vncviewer</command> writes to the X display with 213 several different calls. These calls write to the 214 normal output planes and are compatible with 215 XvPutImage, which writes to an overlay plane. To 216 eliminate artifacts caused by this problem, 217 <command>vncviewer</command> should be modified so that a cached 218 copy of the desktop is available, either as a 219 client-side image or a server-side off-screen pixmap, 220 so that XvPutImage would be the only method for 221 writing to the X display. 222 </para></listitem> 223 <listitem> 224 <para> 225 Although several modern graphics adaptors support 226 hardware scaling using an RGB format (e.g., ATI 227 Radeon, nVidia, etc.), XFree86 drivers typically 228 only implement YUV formats. YUV generally compress 229 the pixel information in some way. For example, two 230 commonly implemented formats, YUY2 and UYVY provide 231 intensity information for every RGB pixel, but only 232 provide chroma and luminance information for pairs 233 of horizontal pixels. Since VNC uses 234 pixel-resolution for communicating updates on the 235 wire, additional artifacts are introduced (because 236 there may not be enough information from the wire to 237 update a pair of pixels). 238 </para> 239 <para> 240 Further, the well-known problem with YUV encoding 241 is even more evident when the image is a desktop 242 instead of a movie. For example, consider a 243 1-pixel-wide vertical window border. If the border 244 changes in color but not intensity (e.g., because a 245 window manager uses color to indicate focus), there 246 may or may not be a change in the YUY2 image, 247 depending on the algorithm used for RGB to YUV 248 conversion and on how the border pixel is ordered in 249 the pair of pixels used by the algorithm. 250 </para> 251 <para> 252 Many of these artifacts could be eliminated if 253 <command>vncviewer</command> cached a complete RGB image of 254 the desktop, and only did the conversion to YUV for 255 properly aligned areas of damage. The remaining artifacts 256 could be eliminated if an RGB format was used with X 257 Video (which may require the extension of existing 258 XFree86 drivers to support RGB). 259 </para> 260 </listitem> 261 <listitem><para> 262 Most modern video cards support exactly one overlay 263 plane that is suitable for use with X Video. 264 Therefore, only one application can use X Video at any 265 given time. This is a severe limitation in a desktop 266 environment. 267 </para></listitem> 268 </itemizedlist> 269 </para> 270 <sect4><title>Implementing the X Video Extension for DMX</title> 271 <para> 272 The user-level API for X Video is fairly simple, but the 273 underlying support required for the full specification 274 is large. However, since the API provides a method to 275 query supported capabilities, a usable subset of X 276 Video can be implemented that would support XvPutImage 277 and little else. This would require support for the 278 following: 279 <itemizedlist> 280 <listitem><para> 281 X Video Extension API calls, including the 282 following: 283 <itemizedlist> 284 <listitem><para>XvQueryExtension</para></listitem> 285 <listitem><para>XvQueryAdaptors</para></listitem> 286 <listitem><para>XvQueryPortAttributes</para></listitem> 287 <listitem><para>XvFreeAdaptorInfo</para></listitem> 288 <listitem><para>XvListImageFormats</para></listitem> 289 <listitem><para>XvGrabPort</para></listitem> 290 <listitem><para>XvCreateImage</para></listitem> 291 <listitem><para>XvPutImage</para></listitem> 292 <listitem><para>XvShmCreateImage</para></listitem> 293 <listitem><para>XvShmPutImage</para></listitem> 294 </itemizedlist> 295 </para></listitem> 296 <listitem><para> 297 Support for querying back-end X Video Extension 298 capabilities. 299 </para></listitem> 300 <listitem><para> 301 Support for sending the image to the back-ends. 302 Because X Video requires sending full images, there 303 may be a trade-off between bandwidth limitations and 304 additional complexity to divide the image up such 305 that is scales properly. 306 </para></listitem> 307 <listitem><para> 308 Possible support for a software fall-back. For 309 example, if all of the back-ends do not support the X 310 Video Extension, software scaling can be implemented 311 such that the image is sent to the back-end with 312 XPutImage. This pathway would have poor 313 performance. 314 </para></listitem> 315 </itemizedlist> 316 </para> 317 </sect4> 318 <sect4><title>Supporting RGB formats for the X Video Extension</title> 319 <para> 320 Assuming an XFree86 driver already supports the X Video 321 Extension, and assuming the target hardware supports an 322 RGB format, then adding support for that format is 323 relatively simple and straightforward. 324 </para> 325 </sect4> 326 </sect3> 327 <sect3><title>Scaling with an XPutImageScaled Extension</title> 328 <para> 329 Instead of (or in addition to) implementing the X Video 330 Extension in DMX, one obvious solution would be to 331 implement a new extension that provides access to 332 hardware-assisted scaled blits, similar to the StretchBlt 333 call available under Windows. This call would scale RGB 334 images and would not use the overlay plane (unlike the X 335 Video Extension). 336 </para> 337 <para> 338 This approach has many of the same advantages and 339 disadvantages as the XCopyAreaScaled Extension, discussed 340 in the next section. Discussion of XPutImageScaled is 341 deferred in favor of XCopyAreaScaled for the following 342 reasons: 343 <itemizedlist> 344 <listitem><para> 345 XPutImageScaled can be emulated with XCopyAreaScaled 346 by first using XPutImage to copy the image to an 347 off-screen pixmap, and then calling XCopyAreaScaled 348 between that off-screen pixmap and the target 349 drawable. 350 </para></listitem> 351 <listitem><para> 352 Since XCopyAreaScaled would copy between two areas of 353 on-screen or off-screen memory, it has additional uses 354 and can be viewed as efficiently providing a superset 355 of XPutImageScaled functionality. 356 </para></listitem> 357 </itemizedlist> 358 </para> 359 </sect3> 360 <sect3><title>Scaling with an XCopyAreaScaled Extension</title> 361 <para> 362 As noted in the previous section, because XCopyAreaScaled 363 provides a superset of the functionality provided by 364 XPutImageScaled, we will consider this extension instead. 365 </para> 366 <para> 367 First, XCopyAreaScaled would provide for RGB scaling 368 between pixmaps (i.e., on-screen or off-screen areas of 369 memory that reside on the video card). Unlike the X Video 370 Extension, which writes into an overlay plane, 371 XCopyAreaScaled would write into the non-overlay areas of 372 the screen. Key points to consider are as follows: 373 <itemizedlist> 374 <listitem><para> 375 Because different planes are involved, the two scaling 376 operations are usually implemented in hardware 377 differently, so an XCopyAreaScaled extension could be 378 added in a manner that would neither conflict with nor 379 interact with the X Video extension in any way. 380 </para></listitem> 381 <listitem><para> 382 The XCopyAreaScaled extension provides new 383 functionality that the X Video Extension does not 384 provide. Based on anecdotal feedback, we believe that 385 many people outside the DMX and VNC communities would 386 be excited about this extension. 387 </para></listitem> 388 <listitem><para> 389 The main drawback to this extension is that it is new 390 and needs to be implemented at the driver level in 391 XFree86 for each video card to be supported. At the 392 present time, it is more likely that the X Video 393 Extension will be implemented for a particular piece 394 hardware because the X Video extension has multimedia 395 uses. However, over time, we would expect the 396 XCopyAreaScaled extension to be implemented along with 397 the X Video extension, especially if it becomes 398 popular. 399 </para></listitem> 400 <listitem><para> 401 Another drawback is that not all modern cards provide 402 support for a simple scaled blit operation. However, 403 these cards usually do provide a 3D pipeline which 404 could be used to provide this functionality in a 405 manner that is transparent to the client application 406 that is using the XCopyAreaScaled extension. However, 407 this implementation pathway would make this extension 408 somewhat more difficult to implement on certain cards. 409 </para></listitem> 410 </itemizedlist> 411 </para> 412 </sect3> 413 <sect3><title>Scaling with OpenGL</title> 414 <para> 415 Another general solution to the scaling problem is to use 416 the texture scaling found in all 3D hardware. This 417 ability is already exposed through OpenGL and can be 418 exploited by clients without X server modification (i.e., 419 other than the ability to support OpenGL). An application 420 using OpenGL would transmit the non-scaled image to the X 421 server as a texture, and would then display a single 422 non-transformed rect using that texture. This also works 423 around the single overlay problem with the X Video 424 Extension as well as the need to implement additional 425 scaled primitive extensions. 426 </para> 427 <para> 428 The downside is that most OpenGL implementations require 429 power of 2 texture sizes and this can be very wasteful of 430 memory if, for example, the application needs to scale a 431 1025x1025 image, which would require a 2048x2048 texture 432 area (even a 640x480 image would require a 1024x512 433 texture). Another downside is that some OpenGL 434 implementations have a limited about of texture memory and 435 cannot handle textures that are very large. For example, 436 they might limit the texture size to 1024x1024. 437 </para> 438 </sect3> 439 </sect2> 440 <sect2><title>Application-transparent Scaling for DMX 441 </title><sect3><title>Back-end Scaling Without Disconnect/Reconnect</title> 442 <para> 443 VNC does scaling on the client side (in the 444 <command>vncviewer</command> application). Implementing a similar 445 solution for DMX would require support in the back-end X 446 servers and, therefore, is not a general solution. 447 </para> 448 <para> 449 XFree86 already implements some support for "scaling" that 450 could be used with DMX: if, in the XF86Config file, 451 multiple Modes are listed in the Display Subsection of the 452 Screen Section, then pressing Ctrl-Alt-Plus and 453 Ctrl-Alt-Minus can be used to iterate through the listed 454 modes. The display dimensions will change to the 455 dimensions in the Modes line, but the logical dimensions 456 of the X server (i.e., the dimensions that Xdmx knows 457 about) will not change. 458 </para> 459 <para> 460 Further, the dimensions of the XFree86 display are under 461 software control (via the XFree86-VidModeExtension), so 462 the Xdmx server could change the screen dimensions on a 463 per-display basis, thereby scaling the information on part 464 of that display. 465 </para> 466 <para> 467 However, this scaling appears to have limited use. For 468 example, assume a 4 by 4 display wall consisting of 16 469 1280x1024 displays. If all of the back-end servers were 470 simultaneously configured to display 640x480, the left 471 hand corner of each display would be magnified, but the 472 composite result would be unreadable. Magnifying one 473 display at a time could be usable, but could have limited 474 utility, since the result would still be no larger than a 475 single display. 476 </para> 477 </sect3> 478 <sect3><title>Back-end Scaling With Disconnect/Reconnect</title> 479 <para> 480 Disconnect and reconnect features are not currently 481 supported in DMX, but are scheduled to be implemented in 482 the future. These features, combined with the 483 XFree86-VidModeExtension Extension, would allow an 484 application to do the following: 485 <itemizedlist> 486 <listitem><para> 487 Disconnect a specific back-end server (via the DMX 488 Extension), 489 </para></listitem> 490 <listitem><para> 491 reconfigure the XFree86 back-end server resolution, 492 and 493 </para></listitem> 494 <listitem><para> 495 reconnect the back-end server to DMX -- at a new 496 origin with the new screen resolution. 497 </para></listitem> 498 </itemizedlist> 499 </para> 500 <para> 501 For example, consider a display wall consisting of 16 502 1280x1024 displays with a total resolution of 5120x4096. 503 All of the screens could be disconnected, repositioned, 504 and reconnected each at a resolution of 640x480. The 505 total resolution of the display wall would be 2560x1920, 506 allowing a view of a selected area approximately 507 one-fourth of the size of the DMX display. This change 508 would be completely application independent (except, 509 perhaps, for a DMX-aware window manager). When work at 510 the increased resolution was completed, the back-end 511 servers could be disconnected, reconfigured, and 512 reconnected for the original 5120x4096 view. 513 </para> 514 <para> 515 Support for this type of scaling can be implemented in a 516 DMX-aware X11 client assuming the DMX server support 517 arbitrary disconnect and reconnect semantics. Because 518 this application cannot be written before 519 disconnect/reconnect is implemented, this solution will 520 not be discussed further in this paper. 521 </para> 522 </sect3> 523 <sect3><title>Server-side Scaling</title> 524 <para> 525 In earlier versions of DMX, a frame buffer was maintained 526 on the server side, and XPutImage was used to move the 527 information from the server to the client (similar to some 528 early VNC implementations). The use of a server-side 529 frame buffer would allow the server to do scaling, but is 530 not a recommended solution because of overall performance 531 issues and server-side memory issues (i.e., the frame 532 buffer would be very large for large display walls). 533 </para> 534 <para> 535 Exploration of this path is not recommended. 536 </para> 537 </sect3> 538 </sect2> 539 <sect2><title>XCreateScaledWindow API</title> 540 <para> 541 The implementation of X Video Extension in DMX, and the use 542 of XvPutImage by applications requiring scaling requires 543 significant changes in DMX Further, XvPutImage is, 544 essentially a scaled blit, and it is only useful for 545 applications which are already using (or can be modified to 546 use) XPutImage. Therefore, a more general API will be 547 discussed as another possibility. 548 </para> 549 <para> 550 X applications typically create windows with the 551 XCreateWindow call. A new extension could provide an 552 XCreateScaledWindow call that could be used in place of the 553 XCreateWindow call and be otherwise transparent to the 554 application. This would allow applications, even those that 555 do not depend on XPutImage, to take advantage of window 556 scaling. In this section we describe how the call would 557 work, what transparency it provides, and how to solve the 558 potential problems that transparency creates. 559 </para> 560 <sect3><title>XCreateWindow</title> 561 <para> 562 The XCreateWindow call takes width and height as 563 parameters. An XCreateScaledWindow call could take all 564 the same parameters, with the addition of a scaling factor. 565 </para> 566 </sect3> 567 <sect3><title>XSetWindowAttributes</title> 568 <para> 569 An X11 window has several attributes that would have to be 570 scaled: 571 <itemizedlist> 572 <listitem><para>Background and border pixmaps</para></listitem> 573 <listitem><para>Border width</para></listitem> 574 <listitem><para>Cursor</para></listitem> 575 </itemizedlist> 576 </para> 577 </sect3> 578 <sect3><title>XGetWindowAttributes, XGetGeometry</title> 579 <para> 580 For transparency, calls that query the window attributes 581 should return unscaled information. This suggests that 582 all unscaled pixmaps and window attributes should be 583 cached. 584 </para> 585 <para> 586 Unfortunately, a window manager requires the scaled 587 geometry to properly decorate the window. The X server 588 can probably determine which client is acting as the 589 window manager (e.g., because that client will select 590 events that are used exclusively by the window manager). 591 However, other Scaled Window Extension aware clients may 592 also need to determine the scaled geometry. Therefore, at 593 least two additional extension calls should be 594 implemented: XGetScaledWindowAttributes and 595 XGetScaledGeometry. 596 </para> 597 </sect3> 598 <sect3><title>Popup and Child window positions</title> 599 <para> 600 Some applications may position popup and child windows 601 based on an unscaled notion of the main window geometry. 602 In this case, additional modifications to the client would 603 be required. 604 </para> 605 </sect3> 606 <sect3><title>Events</title> 607 <para> 608 Most events (e.g., for mouse motion) return information 609 about the coordinates at which the even occurred. These 610 coordinates would have to be modified so that unscaled 611 values were presented to the client. 612 </para> 613 </sect3> 614 <sect3><title>Implementation</title> 615 <para> 616 There are many implementation issues, some of which are 617 similar to the issues involved in implementing the X Video 618 Extension for DMX. The window contents must be scaled, 619 either by performing all operations to a frame buffer and 620 then writing the image to the display (perhaps using 621 hardware scaling support), or by modifying all of the 622 various drawing operations to perform scaling. Because of 623 the complexity involved, the frame buffer option is 624 recommended. 625 </para> 626 </sect3> 627 </sect2> 628 </sect1> 629 630 <sect1><title>Conclusion and Recommendations 631 </title><para> 632 We recommend a three phase implementation strategy, based on 633 how an application could be written to take advantage of 634 scaling: 635 <orderedlist> 636 <listitem> 637 <para> 638 The XCopyAreaScaled extension should be implemented, since 639 this is the ideal solution for applications like VNC, and 640 since making use of this extension will require minimal 641 changes to applications that already use XPutImage or 642 XCopyArea. 643 </para> 644 <para> 645 The initial implementation work would include the design 646 of the X protocol extension, writing this up in the 647 usual format for extension documentation, implementation 648 of the protocol transport pieces in XFree86, 649 implementation of a software fall-back in XFree86 and 650 DMX, one example hardware implementation for XFree86, 651 and implementation of support for this extension in DMX. 652 </para> 653 <para> 654 We suggest implementing the extension first on the ATI 655 Radeon cards. However, since these cards do not provide 656 a 2D scaled blit primitive, the implementation would 657 have to make use of the 3D texture engine to emulate a 658 scaled blit. This is recommended, since other modern 659 graphics cards also do not provide a simple 2D scaled 660 blit operation and an example of the more difficult 661 implementation pathway would be helpful to others. 662 </para> 663 </listitem> 664 <listitem> 665 <para> 666 Until XCopyAreaScaled is widely supported, applications 667 that require scaling will have to fall back to another 668 scaling method. We suggest OpenGL as the first fall-back 669 method because it is widely available and supported by 670 DMX. 671 </para> 672 <para> 673 A project centered around OpenGL-based scaling would 674 implement this scaling in VNC as an example. This work 675 would include re-writing the <command>vncviewer</command> 676 rendering engine to cache a master copy of the desktop 677 image for all operations. 678 </para> 679 </listitem> 680 <listitem> 681 <para> 682 Since OpenGL is not implemented everywhere, and may not 683 provide hardware-assisted performance in every 684 implementation, an application that requires scaling 685 should also fall back to using the X Video Extension. 686 </para> 687 <para> 688 This project would add support for the X Video Extension 689 to DMX and would add support to VNC to take advantage of 690 this extension without introducing artifacts. This 691 would require modifying the <command>vncviewer</command> rendering 692 engine to cache a master copy of the desktop image for 693 all operations. This project should also add support 694 for the RGB format to at least one XFree86 driver (e.g., 695 ATI Radeon). 696 </para> 697 <para> 698 The X Video Extension is one of the few popular 699 extensions that DMX does not support. We recommend 700 implementing the X Video Extension even if scaling is 701 the specific goal of that work. 702 </para> 703 </listitem> 704 </orderedlist> 705 </para> 706 <para> 707 We do <emphasis>not</emphasis> recommend implementation of the 708 XCreateScaledWindow extension because of the complexity 709 involved. We do <emphasis>not</emphasis> recommend implementation of the 710 XPutImageScaled extension because it requires the same amount 711 of work as the XCopyAreaScaled extension, but provides less 712 functionality. Further, server-side scaling with a large 713 frame buffer is <emphasis>not</emphasis> recommended because of the 714 performance implications. 715 </para> 716 <para> 717 The back-end scaling, especially with disconnect/reconnect 718 support should be explored in the future after 719 disconnect/reconnect is implemented, but not at the present 720 time. 721 </para> 722 </sect1> 723 724 </article> 725 <!-- Local Variables: --> 726 <!-- fill-column: 72 --> 727 <!-- End: --> 728