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