recordmydesktop
xfocusnotify
recordmydesktop | xfocusnotify | |
---|---|---|
2 | 3 | |
13 | 8 | |
- | - | |
4.6 | 1.7 | |
5 months ago | about 1 year ago | |
C | C | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
recordmydesktop
-
Disk write buffering and its interactions with write flushes
One of the things I improved in my recordMyDesktop fork [0] was an awful tendency for the frame cache writer to accumulate heaps of dirty pages until background writeback would flush them out.
I had 16GiB of RAM which meant quite large swaths of dirty pages would become buffered while the SSD sat idle until writeback began. This would cause high-FPS full-screen recordings in particular to just become backlogged and start dropping frames / audio dropouts. Just generally broken behavior for a desktop recorder, especially for a defferred-encode mode that's supposed to be optimized for minimizing system-wide effects/overheads during the recording.
The simple solution I found was to proactively initiate writeback regularly via fdatasync() on the cache fd. [1] I haven't decided yet if more should be done to constrain its buffer cache effects though. The cache files will be read back during encoding in post, so if there's enough RAM it can be desirable to enable reading them back entirely from memory instead of having to hit the disks again... but it would also be nice to let the rest of the system's processes keep their stuff in the page cache. memcg can probably be used to find a balanced solution, but I haven't done any experiments yet. Have any of you handled similar scenarios? What did you do?
[0] https://github.com/recordmydesktop/recordmydesktop
[1] https://github.com/recordmydesktop/recordmydesktop/commit/42...
-
Effortless OpenBSD Audio and Desktop Screen Recording Guide
recordMyDesktop[0] should work on any *NIX w/OSS+X, and it defaults to a cached mode with deferred encoding so there's less load on the system during* the recording.
In my experience using Linux+XOrg+ALSA on an X220 ThinkPad it works pretty well, at least in its current form.
Disclaimer: I'm the maintainer of the linked fork, prior to this fork it was ~useless.
[0] https://github.com/recordmydesktop/recordmydesktop
xfocusnotify
- xfocusnotify: X11-tool meant for scripting which exits when a window is focused and prints the respective window-id
-
xfocusnotify: X11-tool which exits when a window is focused and prints the respective window-id
xfocusnotify is meant for scripting and x11-window-management where for some reason you need to know when a new window gets focused and you want to do something with it. It's highly performant because it's written in C and reaches barely 30 lines of code.
xfocusnotify is a tiny X11-tool (only 30 lines of C-code) which exits when a window is focused and prints the respective window-id. It's EWMH-compliant and uses _NET_ACTIVE_WINDOW to determine the focused window.
What are some alternatives?
wcap - Simple and efficient screen recording utility for Windows 10 and 11
clipnotify - Notify on new X clipboard events
berry - :strawberry: A healthy, byte-sized window manager
xplugd - Monitor, keyboard, and mouse plug/unplug helper for X
sowm - An itsy bitsy floating window manager (220~ sloc!).
lucky - Lua-configured input daemon for X
x11k - Keylogger for POSIX systems (linux, freebsd) with X11
screen_capture_lite - cross platform screen/window capturing library