~scoopta

Trackers

~scoopta/wofi

Last active 7 days ago

~scoopta/wlrobs

Last active a month ago

~scoopta/glpaper

Last active 11 months ago

~scoopta/rootbar

Last active 2 years ago

~scoopta/taiga

Last active 3 years ago

~scoopta/markdown_test

Last active 4 years ago

~scoopta/pipbrowser

Last active 4 years ago

#220 [BUG] Cant calculate window size on start 15 days ago

Comment by ~scoopta on ~scoopta/wofi

what are your launch/config options?

#219 [BUG] Blender Failing to launch through wofi 15 days ago

Comment by ~scoopta on ~scoopta/wofi

Can you try to run wofi with -Ddrun-disable_prime=true and see if the issue still persists?

#218 Hide search in the menu - query a month ago

Comment by ~scoopta on ~scoopta/wofi

No, it cannot be fixed with a config option. In fact the way that was setup wasn't quite right. So I fixed it e59e3f58117b. This fix has the added benefit of allowing you to un-hide the search with key_hide_search ...which should've been how this behaved from the start.

REPORTED RESOLVED FIXED

#217 It is possible to create a menu with submenu a month ago

Comment by ~scoopta on ~scoopta/wofi

So this isn't a built in feature, it's likely that this could be done using multi-action entries from a custom mode implementation, in fact I don't really see a reason why not since they basically create a sub menu. Aside from writing your own custom mode this is a feature that could probably be added to drun based on the category information found in desktop files which actually isn't a bad idea. If you are looking to use this from dmenu I'm not sure how to go about creating this for dmenu though, it seems too complicated to do outside of the API.

#26 Average time to render frame much higher with dmabuf capture than pipewire / xdg capture a month ago

Comment by ~scoopta on ~scoopta/wlrobs

yeah, your results are the same as mine. The wl_rt print is right before I hand off to the compositor to do the capture and then START _frame is printed AS SOON as my callback gets run, literally before any other code is run...and that's where all the time is. I'll double check my usage of the dmabuf protocol and make sure I'm not missing something or doing something dumb but it doesn't appear like my code is being slow.

#26 Average time to render frame much higher with dmabuf capture than pipewire / xdg capture a month ago

Comment by ~scoopta on ~scoopta/wlrobs

Can you try the dmabuf_perf_test bookmark? You can clone it with hg clone -r dmabuf_perf_test https://hg.sr.ht/~scoopta/wlrobs or if you already have a local copy of the repo hg pull -ur dmabuf_perf_test. Please run obs from a terminal, you will get A LOT of prints(several per frame). That being said even running this I can capture at 60fps easily so please try that. You don't need to provide all the prints, just a handful is adequate. On my local machine all the time is between wl_rt and START _frame which is compositor time I don't know how to reduce. The prints are in (ms * 10) so a print of 150 is 15.0ms.

#26 Average time to render frame much higher with dmabuf capture than pipewire / xdg capture a month ago

Comment by ~scoopta on ~scoopta/wlrobs

Sure. recording at 62fps, the time is still hovering around 5-7ms. Didn't seem to make much of a difference, maybe slightly lower, can't tell.

hmmmm...that makes the vsync theory sound plausible again lol. At least as far as not being able to capture >refresh rate. My system is no slouch so the differing behaviors at 62FPS doesn't make a lot of sense otherwise. I do wonder why your frame time is so high though. My frame time was quite low at 50FPS and below so if it were all vsync then your frame time shouldn't be high due to your obscene refresh rate.

Recording at 75fps and again time is about 5-7ms, doesn't seem to be having much of an effect on my system. Testing at 170, OBS didn't allow me to set 170 in integer value, so I set it to fractional and did 170/1. Again, average time stays the same, however now its causing relatively frequent dropped frames. This is probably because 170fps will equate to ~ 5.88ms frametime and my average time goes over that frequently to about 6.5ms.

I'm thinking I'll push a branch with timing prints just to see if my theory holds about all the time being stuck in compositor land.

One interesting thing to note is for me when I have the preview on and the properties window open, the average time to render is about double, at 10-12ms or so. Does this indicate its not a Vsync issue?

I now really wish I had opened the properties window during my testing last night. I did not and unfortunately I can't test this thoroughly while at work but it something I will check tonight.

#26 Average time to render frame much higher with dmabuf capture than pipewire / xdg capture a month ago

Comment by ~scoopta on ~scoopta/wlrobs

hmmmm, so just to be clear your frame time is around 6ms at 60FPS on a 170hz display? That's...very interesting and kinda wrecks my hypothesis. That's very interesting. What happens if you try to capture at >60FPS? For me if I set OBS to integer FPS mode and capture at even 62 FPS I start dropping frames with a perfect 16.7ms frame draw time(the time of a 60hz refresh). 60 gives me the frame time that caused you to open this issue. 50 FPS(PAL) gave <1ms. It's very interesting how this only starts to happen around my refresh rate...but you have a different one. Rambling aside:

  • Can you try capturing at 62FPS(since that's the FPS I decided to try with) and let me know what you get?
  • Can you try capturing at a significantly higher FPS, if you want to try 170 you CAN...but I don't want to go so high that we start hitting other unknown performance issues. Maybe like 75? If that works fine see how high you can go before you drop frames
  • What is your laptops refresh rate?
  • If needed I can push a branch with ms timing prints which was the rough way I found where the slowness was and you can build/run that but let's start with the above for now

#26 Average time to render frame much higher with dmabuf capture than pipewire / xdg capture a month ago

Comment by ~scoopta on ~scoopta/wlrobs

One additional interesting behavior to note is the render time seems to change at random but is always consistent. Like if I start OBS sometimes it's 7.7ms, other times it's 13ms. The time it takes is always different yet always consistent until I restart OBS. I'm beginning to wonder if what's happening is OBS is asking for a frame every 16.67ms and the compositor is waiting until vsync to deliver a frame and so the frame is always some number of ms offset from whenever OBS starts asking for frames? The fact that dropping the FPS to 30 in OBS makes the frame render time <1ms supports this hypothesis. As does the fact that attempting to capture at >60FPS causes frame drops constantly. And an exact 16.7ms frame draw time. I wish I had a 120hz monitor but my suspicion at this point is the compositor vsync is eating the entire frame render time and high render times is just a side effect of that.

#26 Average time to render frame much higher with dmabuf capture than pipewire / xdg capture a month ago

Comment by ~scoopta on ~scoopta/wlrobs

Ok...so I did some code profiling and basically ALL of the time is in compositor land. I'm not entirely sure why or if there's anything I can actually do to fix this. Basically from the time I call wl_display_roundtrip to jump into compositor land to the time my _frame callback gets run by the compositor the ENTIRE frame capture time reported by OBS has elapsed. Everything else is basically <1ms. Unless I'm using the dmabuf protocol incorrectly I don't actually know how to fix this. I even restructured my frame caps to not do a calloc every frame because that was kinda a dumb design to start with but there was no improvement.

As far as pipewire cap goes I'm not familiar enough with the architecture but I have a suspicion that unlike my code it isn't waiting for a new frame if one isn't available and so instead of hanging the OBS rendering pipeline it just resubmits the currently available frame. But this is a wild outlandish guess of mine that could be very wrong, I really just don't know. If I'm right that might be why it's rendering with 0.8ms but still lagging for you.