Window Scaling
One of the ideas we had in creating the compositing mechanism was to be able to scale window contents for the user -- having the window contents available as an image provides for lots of flexibility for presentation.
However, while we've seen things like “overview mode” (presenting all of the application windows scaled and tiled for easy selection), we haven't managed to interact with windows in scaled form. That is, until yesterday.
glxgears thinks the window is only 32x32 pixels in size. xfd is scaled by a factor of 2. xlogo is drawn at the normal size.
Two Window Sizes
The key idea for window scaling is to have the X server keep track of two different window sizes -- the sarea occupied by the window within its parent, and the area available for the window contents, including descendents. For now, at least, the origin of the window is the same between these two spaces, although I don't think there's any reason they would have to be.
Current Size. This is the size as seen from outside the window, and as viewed by all clients other than the owner of the window. It reflects the area within the parent occupied by the window, including the area which captures pointer events. This can probably use a better name.
Owner Size. This is the size of the window viewed from inside the window, and as viewed by the owner of the window. When composited, the composite pixmap gets allocated at this size. When automatically composited, the X server will scale the image of the window from this size to the current size.
Clip Lists
Normally, when computing the clip list for a composited window, the X server uses the current size of the window (aka the “borderSize” region) instead of just the porition of the window which is not clipped by the ancestor or sibling windows. This is how we capture output which is covered by those windows and can use it to generate translucent effects.
With an output size set, instead of using the current size, I use the owner size instead. All un-redirected descendents are thus clipped to this overall geometry.
Sub Windows
Descendent windows are left almost entirely alone; they keep their original geometry, both position and size. Because the output sized window retains its original position, all of the usual coordinate transformations 'just work'. Of course, the clipping computations will start with a scaled clip list for the output sized window, so the descendents will have different clipping. There's suprisingly little effect otherwise.
Output Handling
When an owner size is set, the window gets compositing enabled. The composite pixmap is allocate at the owner size instead of the current size. When no compositing manager is running, the automatic compositing painting code in the server now scales the output from the output size to the current size.
Most X applications don't have borders, but I needed to figure out what to do in case one appeared. I decided that the boarder should be the same size in the output and current presentations. That's about the only thing that I could get to make sense; the border is 'outside' the window size, so if you want to make the window contents twice as big, you want to make the window size twice as big, not some function of the border width.
About the only trick was getting the transformation from output size to current size correct in the presence of borders. That took a few iterations, but I finally just wrote down a few equations and solved for the necessary values. Note that Render transforms take destination space coordinates and generate source space coordinates, so they appear “backwards”. While Render supports projective transforms, this one is just scaling and translation, so we just need:
x_output_size = A * x_current_size + B
Now, we want the border width for input and output to be the same, which means:
border_width + output_size = A * (border_width + current_size) + B
border_width = A * border_width + B
Now we can solve for A:
output_size = A * current_size
A = output_size / current_size
And for B:
border_width = output_size / current_size * border_width + B
B = (1 - output_size / current_size) * border_width
With these, we can construct a suitable transformation matrix:
⎡ Ax 0 Bx ⎤
⎢ 0 Ay By ⎥
⎣ 0 0 1 ⎦
Input Handling
Input device root coordinates need to be adjusted for owner sized windows. If you nest an owner sized window inside another owner sized window, then there are two transformations involved.
There are actually two places where these transformations need to be applied:
To compute which window the pointer is in. If an output sized window has descendents, then the position of the pointer within the output window needs to be scaled so that the correct descendent is identified as containing the pointer.
To compute the correct event coordinates when sending events to the window. I decided not to attempt to separate the window owner from other clients for event delivery; all clients see the same coordinates in events.
Both of these require the ability to transform the event coordinates relative to the root window. To do that, we translate from root coordinates to window coordinates, scale by the ratio of output to current size and then translate back:
void
OwnerScaleCoordinate(WindowPtr pWin, double *xd, double *yd)
{
if (wOwnerSized(pWin)) {
*xd = (*xd - pWin->drawable.x) * (double) wOwnerWidth(pWin) /
(double) pWin->drawable.width + pWin->drawable.x;
*yd = (*yd - pWin->drawable.y) * (double) wOwnerHeight(pWin) /
(double) pWin->drawable.height + pWin->drawable.y;
}
}
This moves the device to the scaled location within the output sized windows. Performing this transformation from the root window down to the target window adjusts the position correctly even when there is more than one output sized window among the window ancestry.
Case 1. is easy; XYToWindow, and the associated miSpriteTrace function, already traverse the window tree from the root for each event. Each time we descend through a window, we apply the transformation so that subsequent checks for descendents will check the correct coordinates. At each step, I use OwnerScaleCoordinate for the transformation.
Case 2. means taking an arbitrary window and walking up the window tree to the root and then performing each transformation on the way back down. Right now, I'm doing this recursively, but I'm reasonably sure it could be done iteratively instead:
void
ScaleRootCoordinate(WindowPtr pWin, double *xd, double *yd)
{
if (pWin->parent)
ScaleRootCoordinate(pWin->parent, xd, yd);
OwnerScaleCoordinate(pWin, xd, yd);
}
Events and Replies
To make the illusion for the client work, everything the client hears about the window needs to be adjusted so that the window seems to be the owner size and not the current size.
Input events. The root coordinates are modified as described above, and then the window-relative coordinates are computed as usual—by subtracting the window origin from the root position. That's because the windows are all left in their original location.
ConfigureNotify events. These events are rewritten before being delivered to the owner so that the width and height reflect the owner size. Because window managers send synthetic configure notify events when moving windows, I also had to rewrite those events, or the client would get the wrong size information.
PresentConfigureNotify events. For these, I decided to rewrite the size values for all clients. As these are intended to be used to allocate window buffers for presentation, the right size is always the owner size.
OwnerWindowSizeNotify events. I created a new event so that the compositing manager could track the owner size of all child windows. That's necessary because the X server only performs the output size scaling operation for automatically redirected windows; if the window is manually redirected, then the compositing manager will have to perform the scaling operation instead.
GetGeometry replies. These are rewritten for the window owner to reflect the owner size value. Other clients see the current size instead.
GetImage replies. I haven't done this part yet, but I think I need to scale the window image for clients other than the owner. In particular, xwd currently fails with a Match error when it sees a window with a non-default visual that has an output size smaller than the window size. It tries to perform a GetImage operation using the current size, which fails when the server tries to fetch that rectangle from the owner-sized window pixmap.
Composite Extension Changes
I've stuck all of this stuff into the Composite extension; mostly because you need to use Composite to capture the scaled window output anyways.
12. Composite Events (0.5 and later)
Version 0.5 of the extension defines an event selection mechanism and a couple of events.
COMPOSITEEVENTTYPE {
CompositePixmapNotify = 0
CompositeOwnerWindowSizeNotify = 1
}
Event type delivered in events
COMPOSITEEVENTMASK {
CompositePixmapNotifyMask = 0x0001
CompositeOwnerWindowSizeNotifyMask = 0x0002
}
Event select mask for CompositeSelectInput
⎡
⎢ CompositeSelectInput
⎢
⎢ window: Window
⎢ enable SETofCOMPOSITEEVENTMASK
⎣
This request selects the set of events that will be delivered to the client from the specified window.
CompositePixmapNotify
type: CARD8 XGE event type (35)
extension: CARD8 Composite extension request number
sequence-number: CARD16
length: CARD32 0
evtype: CARD16 CompositePixmapNotify
window: WINDOW
windowWidth: CARD16
windowHeight: CARD16
pixmapWidth: CARD16
pixmapHeight: CARD16
This event is delivered whenever the composite pixmap for a window is created, changed or deleted. When the composite pixmap is deleted, pixmapWidth and pixmapHeight will be zero. The client can call NameWindowPixmap to assign a resource ID for the new pixmap.
13. Output Window Size (0.5 and later)
⎡
⎢ CompositeSetOwnerWindowSize
⎢
⎢ window: Window
⎢ width: CARD16
⎢ height: CARD16
⎣
This request specifies that the owner-visible window size will be set to the provided value, overriding the actual window size as seen by the owner. If composited, the composite pixmap will be created at this size. If automatically composited, the server will scale the output from the owner size to the current window size.
If the window is mapped, an UnmapWindow request is performed automatically first. Then the owner size is set. A CompositeOwnerWindowSizeNotify event is then generated. Finally, if the window was originally mapped, a MapWindow request is performed automatically.
Setting the width and height to zero will clear the owner size value and cause the window to resume normal behavior.
Input events will be scaled from the actual window size to the owner size for all clients.
A Match error is generated if:
- The window is a root window
- One, but not both, of width/height is zero
And, of course, you can retrieve the current size too:
⎡
⎢ CompositeGetOwnerWindowSize
⎢
⎢ window: Window
⎢
⎢ →
⎢
⎢ width: CARD16
⎢ height: CARD16
⎣
This request returns the current owner window size, if set. Otherwise it returns 0,0, indicating that there is no owner window size set.
CompositeOwnerWindowSizeNotify
type: CARD8 XGE event type (35)
extension: CARD8 Composite extension request number
sequence-number: CARD16
length: CARD32 0
evtype: CARD16 CompositeOwnerWindowSizeNotify
window: WINDOW
windowWidth: CARD16
windowHeight: CARD16
ownerWidth: CARD16
ownerHeight: CARD16
This event is generated whenever the owner size of the window is set. windowWidth and windowHeight report the current window size. ownerWidth and ownerHeight report the owner window size.
Git repositories
These changes are in various repositories at gitlab.freedesktop.org all using the “window-scaling” branch:
And here's a sample command line app which modifies the owner scaling value for an existing window:
Current Status
This stuff is all very new; I started writing code on Friday evening and got a simple test case working. I then spent Saturday making most of it work, and today finding a pile of additional cases that needed handling. I know that GetImage is broken; I'm sure lots of other stuff is also not quite right.
I'd love to get feedback on whether the API and feature set seem reasonable or not.