7
7
selected part of the logical DMX area to be displayed using a scaling
8
8
factor. For example, this might allow the contents of a window to be
9
9
magnified for easier viewing. In particular, scaling for the VNC
10
client is explored. _C_o_p_y_r_i_g_h_t _2_0_0_3 _b_y _R_e_d _H_a_t_, _I_n_c_._, _R_a_l_e_i_g_h_, _N_o_r_t_h
10
client is explored. Copyright 2003 by Red Hat, Inc., Raleigh, North
13
13
______________________________________________________________________
52
52
______________________________________________________________________
54
11.. IInnttrroodduuccttiioonn
58
58
The DMX X server (Xdmx) is a proxy server that is designed to allow X
59
59
servers on multiple machines to be combined into a single multi-headed
80
80
will also be explored, since this may lead to a good solution not only
81
81
for vncviewer but also for other applications.
85
85
For reference, here is the original description of the task this paper
88
+o Scaled window support (for VNC)
88
o Scaled window support (for VNC)
90
+o Investigate possibility of implementing a "scaled window"
90
o Investigate possibility of implementing a "scaled window"
93
+o Add XCreateScaledWindow call that could be used in place of
93
o Add XCreateScaledWindow call that could be used in place of
96
+o All primitives drawn to scaled window would be scaled by
96
o All primitives drawn to scaled window would be scaled by
97
97
appropriate (integral?) scaling factor
99
+o Alternate approach: special case VNC support
99
o Alternate approach: special case VNC support
101
22.. PPrreevviioouuss WWoorrkk
103
103
This section reviews relevant previous work.
107
22..11..11.. SSccaalliinngg uunnddeerr VVNNCC
107
2.1.1. Scaling under VNC
109
109
When using the vncviewer program for Windows, it is possible to
110
110
specify a scaling factor (as numerator and denominator). When scaling
118
118
suitably scaled font), and it does not provide any anti-aliasing other
119
119
than that provided by the underlying (Windows-only) system library.
121
22..22.. TThhee XX VViiddeeoo EExxtteennssiioonn
121
2.2. The X Video Extension
123
123
The X Video Extension is a widely-available extension to the X11
124
124
protocol that provides support for streaming video. Integral to this
134
134
plane -- so X Video provides functionality that is fundamentally
135
135
different from that provided by the Windows StrechBlt call.
137
33.. PPoossssiibbllee SSoolluuttiioonnss
137
3. Possible Solutions
139
139
This section briefly discusses possible solutions, including major
140
140
advantages and disadvantages from both the implementation and the end-
141
141
user programmer standpoint.
143
33..11.. VVNNCC--lliikkee SSccaalliinngg
143
3.1. VNC-like Scaling
145
33..11..11.. SSooffttwwaarree SSccaalliinngg
145
3.1.1. Software Scaling
147
147
The vncviewer application could be modified to provide software
148
148
scaling. This is not a general solution, but it does solve one of the
166
166
being re-written in C++ and the forthcoming version 4 has not been
169
33..11..22.. SSccaalliinngg wwiitthh tthhee XX VViiddeeoo EExxtteennssiioonn
169
3.1.2. Scaling with the X Video Extension
171
171
The scaling in the Windows vncviewer application makes use of a scaled
172
172
blit that is supplied by the underlying system library. Several video
189
189
understand the problems that must be solved to make this solution
192
+o As noted under the software scaling section above, vncviewer writes
192
o As noted under the software scaling section above, vncviewer writes
193
193
to the X display with several different calls. These calls write to
194
194
the normal output planes and are compatible with XvPutImage, which
195
195
writes to an overlay plane. To eliminate artifacts caused by this
198
198
side off-screen pixmap, so that XvPutImage would be the only method
199
199
for writing to the X display.
201
+o Although several modern graphics adaptors support hardware scaling
201
o Although several modern graphics adaptors support hardware scaling
202
202
using an RGB format (e.g., ATI Radeon, nVidia, etc.), XFree86
203
203
drivers typically only implement YUV formats. YUV generally
204
204
compress the pixel information in some way. For example, two
225
225
may require the extension of existing XFree86 drivers to support
228
+o Most modern video cards support exactly one overlay plane that is
228
o Most modern video cards support exactly one overlay plane that is
229
229
suitable for use with X Video. Therefore, only one application can
230
230
use X Video at any given time. This is a severe limitation in a
231
231
desktop environment.
233
33..11..22..11.. IImmpplleemmeennttiinngg tthhee XX VViiddeeoo EExxtteennssiioonn ffoorr DDMMXX
233
3.1.2.1. Implementing the X Video Extension for DMX
235
235
The user-level API for X Video is fairly simple, but the underlying
236
236
support required for the full specification is large. However, since
238
238
subset of X Video can be implemented that would support XvPutImage and
239
239
little else. This would require support for the following:
241
+o X Video Extension API calls, including the following:
247
+o XvQueryPortAttributes
251
+o XvListImageFormats
263
+o Support for querying back-end X Video Extension capabilities.
265
+o Support for sending the image to the back-ends. Because X Video
241
o X Video Extension API calls, including the following:
247
o XvQueryPortAttributes
263
o Support for querying back-end X Video Extension capabilities.
265
o Support for sending the image to the back-ends. Because X Video
266
266
requires sending full images, there may be a trade-off between
267
267
bandwidth limitations and additional complexity to divide the image
268
268
up such that is scales properly.
270
+o Possible support for a software fall-back. For example, if all of
270
o Possible support for a software fall-back. For example, if all of
271
271
the back-ends do not support the X Video Extension, software
272
272
scaling can be implemented such that the image is sent to the back-
273
273
end with XPutImage. This pathway would have poor performance.
275
33..11..22..22.. SSuuppppoorrttiinngg RRGGBB ffoorrmmaattss ffoorr tthhee XX VViiddeeoo EExxtteennssiioonn
275
3.1.2.2. Supporting RGB formats for the X Video Extension
277
277
Assuming an XFree86 driver already supports the X Video Extension, and
278
278
assuming the target hardware supports an RGB format, then adding
279
279
support for that format is relatively simple and straightforward.
281
33..11..33.. SSccaalliinngg wwiitthh aann XXPPuuttIImmaaggeeSSccaalleedd EExxtteennssiioonn
281
3.1.3. Scaling with an XPutImageScaled Extension
283
283
Instead of (or in addition to) implementing the X Video Extension in
284
284
DMX, one obvious solution would be to implement a new extension that
292
292
of XPutImageScaled is deferred in favor of XCopyAreaScaled for the
293
293
following reasons:
295
+o XPutImageScaled can be emulated with XCopyAreaScaled by first using
295
o XPutImageScaled can be emulated with XCopyAreaScaled by first using
296
296
XPutImage to copy the image to an off-screen pixmap, and then
297
297
calling XCopyAreaScaled between that off-screen pixmap and the
300
+o Since XCopyAreaScaled would copy between two areas of on-screen or
300
o Since XCopyAreaScaled would copy between two areas of on-screen or
301
301
off-screen memory, it has additional uses and can be viewed as
302
302
efficiently providing a superset of XPutImageScaled functionality.
304
33..11..44.. SSccaalliinngg wwiitthh aann XXCCooppyyAArreeaaSSccaalleedd EExxtteennssiioonn
304
3.1.4. Scaling with an XCopyAreaScaled Extension
306
306
As noted in the previous section, because XCopyAreaScaled provides a
307
307
superset of the functionality provided by XPutImageScaled, we will
313
313
overlay plane, XCopyAreaScaled would write into the non-overlay areas
314
314
of the screen. Key points to consider are as follows:
316
+o Because different planes are involved, the two scaling operations
316
o Because different planes are involved, the two scaling operations
317
317
are usually implemented in hardware differently, so an
318
318
XCopyAreaScaled extension could be added in a manner that would
319
319
neither conflict with nor interact with the X Video extension in
322
+o The XCopyAreaScaled extension provides new functionality that the X
322
o The XCopyAreaScaled extension provides new functionality that the X
323
323
Video Extension does not provide. Based on anecdotal feedback, we
324
324
believe that many people outside the DMX and VNC communities would
325
325
be excited about this extension.
327
+o The main drawback to this extension is that it is new and needs to
327
o The main drawback to this extension is that it is new and needs to
328
328
be implemented at the driver level in XFree86 for each video card
329
329
to be supported. At the present time, it is more likely that the X
330
330
Video Extension will be implemented for a particular piece hardware
333
333
implemented along with the X Video extension, especially if it
336
+o Another drawback is that not all modern cards provide support for a
336
o Another drawback is that not all modern cards provide support for a
337
337
simple scaled blit operation. However, these cards usually do
338
338
provide a 3D pipeline which could be used to provide this
339
339
functionality in a manner that is transparent to the client
341
341
this implementation pathway would make this extension somewhat more
342
342
difficult to implement on certain cards.
344
33..11..55.. SSccaalliinngg wwiitthh OOppeennGGLL
344
3.1.5. Scaling with OpenGL
346
346
Another general solution to the scaling problem is to use the texture
347
347
scaling found in all 3D hardware. This ability is already exposed
362
362
handle textures that are very large. For example, they might limit the
363
363
texture size to 1024x1024.
365
33..22.. AApppplliiccaattiioonn--ttrraannssppaarreenntt SSccaalliinngg ffoorr DDMMXX
365
3.2. Application-transparent Scaling for DMX
367
33..22..11.. BBaacckk--eenndd SSccaalliinngg WWiitthhoouutt DDiissccoonnnneecctt//RReeccoonnnneecctt
367
3.2.1. Back-end Scaling Without Disconnect/Reconnect
369
369
VNC does scaling on the client side (in the vncviewer application).
370
370
Implementing a similar solution for DMX would require support in the
396
33..22..22.. BBaacckk--eenndd SSccaalliinngg WWiitthh DDiissccoonnnneecctt//RReeccoonnnneecctt
396
3.2.2. Back-end Scaling With Disconnect/Reconnect
398
398
Disconnect and reconnect features are not currently supported in DMX,
399
399
but are scheduled to be implemented in the future. These features,
400
400
combined with the XFree86-VidModeExtension Extension, would allow an
401
401
application to do the following:
403
+o Disconnect a specific back-end server (via the DMX Extension),
405
+o reconfigure the XFree86 back-end server resolution, and
407
+o reconnect the back-end server to DMX -- at a new origin with the
403
o Disconnect a specific back-end server (via the DMX Extension),
405
o reconfigure the XFree86 back-end server resolution, and
407
o reconnect the back-end server to DMX -- at a new origin with the
408
408
new screen resolution.
410
410
For example, consider a display wall consisting of 16 1280x1024
424
424
disconnect/reconnect is implemented, this solution will not be
425
425
discussed further in this paper.
427
33..22..33.. SSeerrvveerr--ssiiddee SSccaalliinngg
427
3.2.3. Server-side Scaling
429
429
In earlier versions of DMX, a frame buffer was maintained on the
430
430
server side, and XPutImage was used to move the information from the
437
437
Exploration of this path is not recommended.
439
33..33.. XXCCrreeaatteeSSccaalleeddWWiinnddooww AAPPII
439
3.3. XCreateScaledWindow API
441
441
The implementation of X Video Extension in DMX, and the use of
442
442
XvPutImage by applications requiring scaling requires significant
454
454
provides, and how to solve the potential problems that transparency
457
33..33..11.. XXCCrreeaatteeWWiinnddooww
459
459
The XCreateWindow call takes width and height as parameters. An
460
460
XCreateScaledWindow call could take all the same parameters, with the
461
461
addition of a scaling factor.
462
33..33..22.. XXSSeettWWiinnddoowwAAttttrriibbuutteess
462
3.3.2. XSetWindowAttributes
464
464
An X11 window has several attributes that would have to be scaled:
466
+o Background and border pixmaps
472
33..33..33.. XXGGeettWWiinnddoowwAAttttrriibbuutteess,, XXGGeettGGeeoommeettrryy
466
o Background and border pixmaps
472
3.3.3. XGetWindowAttributes, XGetGeometry
474
474
For transparency, calls that query the window attributes should return
475
475
unscaled information. This suggests that all unscaled pixmaps and
484
484
additional extension calls should be implemented:
485
485
XGetScaledWindowAttributes and XGetScaledGeometry.
487
33..33..44.. PPooppuupp aanndd CChhiilldd wwiinnddooww ppoossiittiioonnss
487
3.3.4. Popup and Child window positions
489
489
Some applications may position popup and child windows based on an
490
490
unscaled notion of the main window geometry. In this case, additional
491
491
modifications to the client would be required.
493
33..33..55.. EEvveennttss
495
495
Most events (e.g., for mouse motion) return information about the
496
496
coordinates at which the even occurred. These coordinates would have
497
497
to be modified so that unscaled values were presented to the client.
499
33..33..66.. IImmpplleemmeennttaattiioonn
499
3.3.6. Implementation
501
501
There are many implementation issues, some of which are similar to the
502
502
issues involved in implementing the X Video Extension for DMX. The
506
506
drawing operations to perform scaling. Because of the complexity
507
507
involved, the frame buffer option is recommended.
509
44.. CCoonncclluussiioonn aanndd RReeccoommmmeennddaattiioonnss
509
4. Conclusion and Recommendations
511
511
We recommend a three phase implementation strategy, based on how an
512
512
application could be written to take advantage of scaling:
557
557
does not support. We recommend implementing the X Video Extension
558
558
even if scaling is the specific goal of that work.
560
We do nnoott recommend implementation of the XCreateScaledWindow
561
extension because of the complexity involved. We do nnoott recommend
560
We do not recommend implementation of the XCreateScaledWindow
561
extension because of the complexity involved. We do not recommend
562
562
implementation of the XPutImageScaled extension because it requires
563
563
the same amount of work as the XCopyAreaScaled extension, but provides
564
564
less functionality. Further, server-side scaling with a large frame
565
buffer is nnoott recommended because of the performance implications.
565
buffer is not recommended because of the performance implications.
567
567
The back-end scaling, especially with disconnect/reconnect support
568
568
should be explored in the future after disconnect/reconnect is
added
removed
hw/dmx/doc/scaled.txt
