Compositing window manager, window resize

[Kamal123]

Hi, I have a confusion regarding window resize, first of all whenever new window is created it creates an off screen buffer with size matching the window size, like if my window is 500x500 the off screen buffer size is 500x500x4 but what if window is resized? Do I need to remap the shared memory buffer to a new size by freeing the previous one? Or from beginning itself the window off screen buffer size is set to the size of screen resolution?

Thanks in advance.

[thewrongchristian]

Hi, I have a confusion regarding window resize, first of all whenever new window is created it creates an off screen buffer with size matching the window size, like if my window is 500x500 the off screen buffer size is 500x500x4 but what if window is resized? Do I need to remap the shared memory buffer to a new size by freeing the previous one? Or from beginning itself the window off screen buffer size is set to the size of screen resolution?

Thanks in advance.

Seems a bit wasteful to have a screen sized buffer for each window, if each window is using only a subset of the screen.

If the window resizes, either resize the off screen buffer or allocate a new one. It'll need repainting anyway, so it probably matters little whether you reuse some of the existing memory or allocate new memory.

Still, might be worth rounding up dimensions to the next power of two, which can accommodate small further resizes, but that would be an optimisation and an implementation detail. Get it working first.

[iProgramInCpp]

Still, might be worth rounding up dimensions to the next power of two, which can accommodate small further resizes, but that would be an optimisation and an implementation detail. Get it working first.

Thanks, I was just wondering how I could get smooth window resizing without abusing the crap out of my allocate() and free() functions.

[thewrongchristian]

Still, might be worth rounding up dimensions to the next power of two, which can accommodate small further resizes, but that would be an optimisation and an implementation detail. Get it working first.

Thanks, I was just wondering how I could get smooth window resizing without abusing the crap out of my allocate() and free() functions.

I wouldn't worry too much about smoothness. From the window manager POV, you just send a message to the client window that its window has resized, and resizing the composited window in the process.

The resized window buffer can be initialized to the contents of the old window I guess, so that even if the client hasn't redrawn yet, the window contents will be at least coherent (if mis-sized now.) That copy would imply you're best to allocate the new window buffer, copy the contents, then release the old window buffer, rather than resizing the buffer in place.

How your client then decides how to handle the redraw messages then defines the smoothness of the resize:

- If individual redraws are handled as they come in, then the window resize will appear to be smooth and follow the window borders as smoothly as possible. The problem with this is if you resize too quickly, the redrawing can lag behind the resized borders, and make for a poor use experience as a result.
- If all outstanding redraws are aggregated into a single redraw action, then the resize will jump less smoothly, but should better keep up with the resized window borders. The event loop would consume redraw events by just indicating that a redraw is required by setting a boolean flag. Then the redraw actually occurs in either another thread, or when no more events are outstanding. On a really fast machine, the resize will still look smooth if the redraw can keep up with the outstanding redraw messages.