<novakane>
man, at the pace river development is going right now I kinda expect to see the new windows management ready next week :P
fitrh has joined #river
<bw>
what's the new windows management?
fitrh has quit [Read error: Connection reset by peer]
fitrh has joined #river
fitrh has quit [Quit: fitrh]
linkert has joined #river
<ifreund>
bw: I have loose plans to push even more window management policy out of river into the "layout generators"
<ifreund>
the layout generators might start looking more like window managers, not sure yet where exactly the split will end up
<ifreund>
not going to happen till after 0.3.0 though
dbuckley has joined #river
jao has joined #river
upsala has joined #river
<upsala>
@ifreund the fix you just pushed for the mpv resizing, does that work as expected for you? For me it is lagging really hard
<ifreund>
upsala: it does indeed work for me...
<upsala>
Ah it might be something on my end then
<upsala>
I'll investigate
<ifreund>
it could also be that I'm using a relatively powerful PC, I can try on an old laptop
<upsala>
The resizing does work as expected but it is really slow
<upsala>
Nah no need, my PC isn't that bad, ryzen 3600
<ifreund>
hmm, might be worth checking your river logs to see if anything looks strange, would you mind trying with `river -log-level debug 2> /tmp/river.log` or similar and dropping that in a pastebin?
<upsala>
Sure I'll do that
upsala has quit [Remote host closed the connection]
upsala has joined #river
upsala has quit [Remote host closed the connection]
<ifreund>
hmm, I can reproduce some lag with mpv in a nested river session, but only in a nested session
upsala has joined #river
upsala has quit [Remote host closed the connection]
upsala has joined #river
<upsala>
Ok sorry for taking so long... had some issues with my new gpu
<upsala>
the log file is 1700 lines, want me to put it in a pastebin anyways? Or upload it to filen or something?
<upsala>
As a sidenode I upgraded from an rx480 to a 6700xt today, not sure if that could have anything to do with it, and I put the monitor into one of the DP ports without really checking which one, if that could have anything to do with it
<tleydxdy[m]>
I have r5800x+rx580, so would be interesting to see if I run into it
<ifreund>
hmm, I should really add timestamps to the logging. It would help with debugging lag-related stuff like this
<upsala>
It won't allow me to resize fast at all, I can drag my mouse 10cm and it resizes about 20 pixels. Once the video is buffered it works a little better it seems
<ifreund>
does it behave the same if the video is paused?
<ifreund>
and does it behave the same regardless of the video being played?
<ifreund>
thanks for the log, I'm afraid there's not too much to be gleaned from it though unfortunately
upsala has quit [Remote host closed the connection]
angry_vincent has quit [Ping timeout: 255 seconds]
upsala has joined #river
<upsala>
river just crashed while resizing
<upsala>
One sec let me get the error message I got
angry_vincent has joined #river
angry_vincent has quit [Changing host]
angry_vincent has joined #river
<ifreund>
oh fun, thanks
<upsala>
Ok, how do I get the info that is shown on tty1 so I can copy it? I never needed this...
upsala has quit [Remote host closed the connection]
<ifreund>
hmm, I've always just redirected output into a file
upsala has joined #river
<upsala>
Ok I can somewhat reproduce the crashing, I logged it one sec, I'll just put the last couple of lines in
<upsala>
I think this happens when, because of this lagging stuff, the border would go outside the space of the desktop
<ifreund>
that seems possible, it's hard to know without a stack trace though
<ifreund>
do you happen to be using systemd? if so could you `coredumpctl gdb` and give me the output of `bt`?
<ifreund>
if not, I think the easiest way to get a stack trace would be to build river in debug mode, it should then print a stacktrace itself if it crashes
<upsala>
would it help you if I recorded a video of the issue?
<ifreund>
Yeah, that could be helpful so I can better visualize it :)
<upsala>
When the video is playing I am moving my mouse pretty fast, just so you know
<upsala>
It's not like I am trying to resize it that slowly
<ifreund>
Yeah, river only updates the cursor position based on how much the client has actually resized now
<ifreund>
which feels great and smooth when the client commits a new buffer quickly but when the client doesn't we get what you see here...
<upsala>
Do you have an idea what the issue might be?
<ifreund>
I'm not sure if mpv is actually capable of smoothly resizing any faster than what we see while playing a video.
<ifreund>
I think I probably need to unlock the cursor from the size of the client and go back to having it indicate what we've requested of the client
<ifreund>
and not throttle the speed of the resize by the speed the client smoothly resizes at
<upsala>
resizing with keyboard works fine btw
<ifreund>
It looks like I can reproduce the issue well enough on my thinkpad to be able to test myself now
<upsala>
Ok cool
<ifreund>
thanks for reporting and helping out!
<angry_vincent>
ifreund: how can i build river from git?
<leon-p>
I wonder if there is a workaround. Locking the cursor is prety neat, would be a shame to go back just because some clients don't work well
<ifreund>
angry_vincent: have you tried reading the README.md file?
<ifreund>
it has build instructions
<upsala>
Oh one more thing, when I put the cursor in bottom middle and try to resize nothing happens
<angry_vincent>
no, not really. was relying on port
<ifreund>
upsala: yeah that's expected, mpv doesn't allow resizing from that edge...
<upsala>
Interesting, never realized that before
<ifreund>
it may have been broken before, not sure :D
<ifreund>
leon-p: we'd still lock the cursor to the bounds allowed by the output and for clients that are fast enough it should feel pretty much the same
<leon-p>
fair
kotto has joined #river
upsala has quit [Remote host closed the connection]
upsala has joined #river
<upsala>
I just tried it on a debug build of Hyprland and indeed the resizing there is also really slow
<upsala>
in awesomewm (X11) it's fast but that doesn't redraw the full video each time, only every couple of frames it seems
<upsala>
No that is worded wrong, it updates the video size not every frame
<upsala>
ifreund: just wondering what kind of cpu do you have that you don't see the issue?
<ifreund>
upsala: I have a ryzen 3700X and an RX 480 gpu
<ifreund>
I think the bottleneck here is most likely mpv's usage of the gpu to render new frames, perhaps it's hitting a slow path on your gpu hardware somehow
<upsala>
Hmm as I said I just changed my gpu today, rx480 out, 6700xt in, haven't really done anything else. Should I be doing anything after installing the new card?
<ifreund>
I don't think so though I'm no expert on that level of the graphics stack
<ifreund>
mpv should print out whether it's using the gpu or not I think
<upsala>
yeah it is, just a thought but maybe you're right. Everything else works as expected
<upsala>
This might also just be a wlroots issue no?
<upsala>
I'll try on gnome wayland tomorrow when I have some time
<ifreund>
upsala: it's far more likely to be a river issue than a wlroots issue tbh
<ifreund>
note that mpv resizing on sway is totally funky right now as well though...
<ifreund>
I've got some ideas on how to improve what river is doing here that should make things smoother in the case that mpv can't keep up, just need to find time to implement them
icp has joined #river
<upsala>
Well take your time, I really appreciate the work you're doing. riverwm is the closest I can get to awesomewm on wayland so far
<ifreund>
thanks for the kind words :)
<icp>
If zig 0.11 comes before river 0.3, will it require that for building river?
<ifreund>
icp: if the timing is close I'll probably do the same thing I've done for 0.1 and 0.2, river 0.3.0 will stick with zig 0.10 and river 0.3.1 will require zig 0.11
<ifreund>
I think it's likely I can get river 0.3 out before zig 0.11 releases depending on my schedule
angry_vincent has quit [Remote host closed the connection]
<icp>
yeah, minor version bump for zig updates probably makes most sense
<icp>
I was just curious after seeing the 0.10.0 bug fix commit for CI
<icp>
btw is zig 0.11 scheduled for June?
upsala has quit [Remote host closed the connection]
<ifreund>
icp: ah, that's a pretty special case. For some reason zig upstream didn't provide a FreeBSD binary for 0.10.1 and we rely on the https://ziglang.org/download binaries for CI to avoid depending too much on the distros being up to date
<ifreund>
I don't know exactly when zig 0.11 is planned to be released. It will probably be at least a month after llvm 16 is tagged
<kolunmi>
also, minor, but I found a typo in /completions/fish/riverctl.fish on line 14: 'focused' is misspelled
<ifreund>
kolunmi: I'm not opposed to nushell completions, just note that I'm not going to put much effort into learning how to add new stuff to them as river changes
<ifreund>
that goes for all the completions though really
<ifreund>
They're just best effort things that are mostly better than nothing but not really polished
<ifreund>
I just wish there was a cross-shell solution for this so everyone didn't have to maintain N different versions of effectively the same thing
IchikaZou has quit [Remote host closed the connection]
<icp>
I have been using carapace-bin almost since it's inception together with nushell and it's works quite well for my needs ootb in most cases
<kolunmi>
Nushell completions are pretty easy, however it seems that it doesn't support single `-` word options or subcommands after an argument, such as in riverctl's `input name command` format
<kolunmi>
And yeah I don't think that cross-shell solution will ever exist
<ifreund>
kolunmi: where do nushell users typically get their completions from? is there some centralized repository or do people try to upstream nushell completions into all programs they use?
<ifreund>
it seems like carapace-bin would be very attractive for users of non bash/zsh/fish shells that aren't yet as widespread
<ifreund>
hmm, I'm not really inclined to accept nushell completions into river's repo if nushell users in general are already used to getting them from a centralized source
<ifreund>
it makes much more sense for completions to be maintained by people that actually understand the shell language at hand
icp has quit [Ping timeout: 248 seconds]
<kolunmi>
eh I think it's less of a centralized source and more a repository of examples on how to write nushell completions for personal use
<kolunmi>
But I understand your position
kolunmi has quit [Quit: Client closed]
<tleydxdy[m]>
this is me rebasing the smart border patch again, but not really related to that. I noticed that all over river the box for the view plus border gets calculated, do you think it's better to have it calculated once in LayoutDemand.zig and then used instead?
<ifreund>
tleydxdy[m]: the better fix would be to subtract the border size when sending configures rather than add it everywhere
<ifreund>
I'll probabably do that at some point
<tleydxdy[m]>
but the configure size is an suggestion right?
<ifreund>
that's not really relevant to that change?
<ifreund>
It's a bit more than a suggestion in some cases, all the details are in the xdg-shell protocol
<ifreund>
I wish the wayland authors had been bold enough to just make it a protocol error to commit a buffer of the wrong size, it would simplify everything a lto
<tleydxdy[m]>
I mean it is annoying me because everywhere it checks ssd for border width I need to update for smart border
<tleydxdy[m]>
but that's not really a big deal as it stands
<tleydxdy[m]>
just cus it's duplicating logic everywhere
<ifreund>
like I said, I'll probably fix some point so there's only one place we need to subtract it
<tleydxdy[m]>
but say you tell it to configure for 100x200 and it gives back 150x150, don't the border need to be added again?
<ifreund>
yeah, so two places I guess
<ifreund>
still better than the status quo probably
<ifreund>
i've got bigger fish to fry right now though
<tleydxdy[m]>
np I think I can live with some borders while things setting down tbh :)
<tleydxdy[m]>
seems like the window logic still got some ways to go
<tleydxdy[m]>
btw mpv resizes fine for me when paused
<tleydxdy[m]>
and I won't nessesarily call it laggy but definitly slow when playing
<ifreund>
part of me wants to just tell every client that it is maximized all the time and send protocol errors if they don't submit a buffer of the right size
<tleydxdy[m]>
could be a policy decision left for the future window managers ;)
<tleydxdy[m]>
actually, I tried resizing brave it's a bit faster but still definitely not as fast as before
<tleydxdy[m]>
buttery do seems to be the right word
<ifreund>
looks like interactive resize of mpv while mpv is playing a video is just as slow in weston as in river on my old x220
<ifreund>
the difference is that river's cursor is locked to the speed that mpv resizes at and that there appear to be a few bugs left to track down there
<ifreund>
I'm not sure if true interactive resize actually gets any faster than this with how mpv's rendering loop works on wayland (it's not pretty)
<tleydxdy[m]>
I feel like the cursor ought to take priority, and the resize requests can be throttled
<tleydxdy[m]>
at least from a UX prespective
<ifreund>
throttled by what?
<tleydxdy[m]>
by the rate client replies
<ifreund>
it already is
<tleydxdy[m]>
I guess just need to untie the cursor position then
<ifreund>
it's not really that simple unfortunately
<ifreund>
I'd like to ammend my statement to "I don't think smooth interactive resize gets any faster than what river has currently"
<ifreund>
what we can change is to make the resize less smooth and happen in larger jumps for clients that fail to keep up
<ifreund>
still easier said than done though due to the fact that we don't know what size the client is going to take until it actually commits
<ifreund>
I'll figure it out eventually, but not tonight
<tleydxdy[m]>
I'm thinking the cursor move in whatever path the user commands, and during that time river sends the configure for as fast as the client can keep up
<tleydxdy[m]>
and each configure send is based on the current cursor position
<tleydxdy[m]>
s/the current/ the most current/
<ifreund>
yes, that's >what we can change is to make the resize less smooth and happen in larger jumps for clients that fail to keep up
<ifreund>
but that's not the hard part, the hard part is synchronizing the state to know what size to request from the client in the configures and properly clamp the window to the output
<ifreund>
despite the fact that we don't actually know what dimensions the window will take
<tleydxdy[m]>
it's the same smoothness tho, the window size is still changing as fast as possible
<tleydxdy[m]>
i.e. same "fps" just object moving faster
<ifreund>
to me "smooth" is the opposite of "jumpy" and something being smooth implies that you don't see any abrupt change in state
<tleydxdy[m]>
in that case moving a window would need to be capped at a speed determined by the screen refresh rate