OSDev.org

The Place to Start for Operating System Developers
It is currently Tue May 17, 2022 9:37 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Compositing window manager, window resize
PostPosted: Mon Jan 17, 2022 8:50 am 
Offline
Member
Member

Joined: Fri Nov 01, 2019 1:17 am
Posts: 75
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.


Top
 Profile  
 
 Post subject: Re: Compositing window manager, window resize
PostPosted: Mon Jan 17, 2022 4:19 pm 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 am
Posts: 279
Kamal123 wrote:
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.


Top
 Profile  
 
 Post subject: Re: Compositing window manager, window resize
PostPosted: Tue Jan 18, 2022 1:38 am 
Offline
Member
Member

Joined: Sun Apr 21, 2019 7:39 am
Posts: 55
thewrongchristian wrote:
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.


Top
 Profile  
 
 Post subject: Re: Compositing window manager, window resize
PostPosted: Tue Jan 18, 2022 9:47 am 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 am
Posts: 279
iProgramInCpp wrote:
thewrongchristian wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group