Floating container with delayed redraw #301

Closed
opened 9 months ago by sv · 7 comments
sv commented 9 months ago

Thinking about what mr. @dnkl has said about redraws in #283 , especially this part:

So while I'm not going to close this straight away, I wonder if something much more simple would be good enough

I wonder if it is possible/reasonable/not-totally-insane to do something like this:

  1. When foot's window is resized, do not send the new coordinates to the client immediately, keep drawing it as nothing has happened. Don't mind the cropped content.

  2. If foot's window stays unchanged for >500ms — send new size to the client, continue as usual.

Pros:

  1. No "visual effects" involved.
  2. Computationally (much) easier than #283
  3. Would still remove a good chunk of jumps & blinks.
Thinking about what mr. @dnkl has said about redraws in https://codeberg.org/dnkl/foot/issues/283#issuecomment-168421 , especially this part: > So while I'm not going to close this straight away, I wonder if something much more simple would be good enough I wonder if it is possible/reasonable/not-totally-insane to do something like this: 1. When `foot`'s window is resized, do not send the new coordinates to the client immediately, keep drawing it as nothing has happened. Don't mind the cropped content. 2. If `foot`'s window stays unchanged for >500ms — send new size to the client, continue as usual. **Pros:** 1. No "visual effects" involved. 2. Computationally (much) easier than https://codeberg.org/dnkl/foot/issues/283 3. Would still remove a good chunk of jumps & blinks.
dnkl added the
enhancement
label 9 months ago
Owner

This is exactly what kitty is doing, I believe.

I'm personally not a big fan of it, but lets keep this issue open for discussion.

An even simpler solution would be to not send the new dimensions to the client at all, until the resize is done. It would simplify the login in foot by a great deal, since it doesn't require us using a timer.

I'm not seriously suggesting it, as I think it would be to take things too far. But just wanted to bring up the "extreme" version of what you're suggesting.

This is **exactly** what kitty is doing, I believe. I'm personally not a big fan of it, but lets keep this issue open for discussion. An even simpler solution would be to not send the new dimensions to the client at all, until the resize is done. It would simplify the login in foot by a great deal, since it doesn't require us using a timer. I'm not seriously suggesting it, as I think it would be to take things too far. But just wanted to bring up the "extreme" version of what you're suggesting.
sv commented 9 months ago
Poster

An even simpler solution would be to not send the new dimensions to the client at all, until the resize is done

...and wait X amount of msec to ensure that user isn't fiddling with the window?

But just wanted to bring up the "extreme" version of what you're suggesting.

What are the downsides? Sorry, it's quite late Down Under, I will try to think about edge cases tomorrow.

> An even simpler solution would be to not send the new dimensions to the client at all, until the resize is done ..._and_ wait X amount of msec to ensure that user isn't fiddling with the window? > But just wanted to bring up the "extreme" version of what you're suggesting. What are the downsides? Sorry, it's quite late Down Under, I will try to think about edge cases tomorrow.
Owner

...and wait X amount of msec to ensure that user isn't fiddling with the window?

No. In Wayland, "resizing" is a property of the window. I.e. when the user starts an interactive resize, the compositor sends a state-update to foot, indicating that the window is now being resized. Typically when the user starts dragging the borders.

Then, when the user stops resizing, a new event is sent to foot. Typically when the user releases the mouse button.

In other words, you'd be able to fiddle with the window for as long as you like - foot would not send the new dimensions to the client until the user releases the mouse button. Or whatever method he/she is using to do the resize.

What are the downsides? Sorry, it's quite late Down Under, I will try to think about edge cases tomorrow.

That last part would be the downside; you don't get to see the content being updated until you've released the mouse button.

Having a timeout, and forcing the client to update occasionally, is better, but more complex code wise.

> ...and wait X amount of msec to ensure that user isn't fiddling with the window? No. In Wayland, "resizing" is a property of the window. I.e. when the user starts an interactive resize, the compositor sends a state-update to foot, indicating that the window is now being resized. Typically when the user starts dragging the borders. Then, when the user stops resizing, a new event is sent to foot. Typically when the user releases the mouse button. In other words, you'd be able to fiddle with the window for as long as you like - foot would **not** send the new dimensions to the client until the user releases the mouse button. Or whatever method he/she is using to do the resize. > What are the downsides? Sorry, it's quite late Down Under, I will try to think about edge cases tomorrow. That last part would be the downside; you don't get to see the content being updated until you've released the mouse button. Having a timeout, and forcing the client to update occasionally, is better, but more complex code wise.
Owner

I've tested current foot with a couple of different alt-screen applications, and it really comes down to how fast the application is redrawing.

less usually looks beautiful; no glitches, flashes, jumping cursors or anything.

emacs is pretty bad - you can see a lot of half-updated frames.

vim was somewhere in between.

In all cases I suspect the amount of highlighting etc is a factor since it means the client has to push more data to foot.

I've tested current foot with a couple of different alt-screen applications, and it really comes down to how fast the application is redrawing. `less` usually looks beautiful; no glitches, flashes, jumping cursors or anything. `emacs` is pretty bad - you can see a lot of half-updated frames. `vim` was somewhere in between. In all cases I suspect the amount of highlighting etc is a factor since it means the client has to push more data to foot.
Owner

@sv POC implementing a configurable delay in #304. Requires Sway master.

@sv POC implementing a configurable delay in https://codeberg.org/dnkl/foot/pulls/304. Requires Sway master.
sv commented 9 months ago
Poster

Requires Sway master.

/me patiently waiting for wlroots to trickle-down from "experimental" into "testing" which would allow to build above-mentioned master.

> Requires Sway master. /me patiently waiting for `wlroots` to trickle-down from "experimental" into "testing" which would allow to build above-mentioned master.
Owner

@sv you can easily build sway with wlroots master without touching your base system; just git clone wlroots into <sway-src>/subprojets. When you configure your sway build directory, meson should pick up and prefer the wlroots subproject over your system wlroots.

The resulting sway binary can be run from the build directory. No need to install anything, or touch the base system in any way.

@sv you can easily build sway with wlroots master without touching your base system; just `git clone` wlroots into `<sway-src>/subprojets`. When you configure your sway build directory, meson should pick up and prefer the wlroots subproject over your system wlroots. The resulting sway binary can be run from the build directory. No need to install anything, or touch the base system in any way.
dnkl closed this issue 9 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.