recordmydesktop VS berry

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...

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

I downloaded the latest release as a zip file here - https://github.com/JLErvin/berry/releases

FWIW, it’s 34KB and while it’s only the source, that seems pretty small. I haven’t gone through the build process to figure out the executable though.

This is a great article and I remember reading it numerous times while I was implementing my own window manager.

For someone interested in working on a really fun and rewarding hobby project a WM is a great one to look into since there are so many resources starting from really small implementations:

- https://github.com/mackstann/tinywm

- https://github.com/venam/2bwm

- https://github.com/dylanaraps/sowm

- https://github.com/dcat/swm

- https://github.com/JLErvin/berry

Which are great at introducing the concepts and allowing you to grok the required libraries.

There are also a bunch of more full featured window managers which will introduce you to more advanced topics:

- https://github.com/baskerville/bspwm

- https://github.com/herbstluftwm/herbstluftwm

- https://www.nongnu.org/ratpoison/

- https://github.com/conformal/spectrwm

Gradually as you get more familiar with the ecosystem a few questions will come up:

Should I use X11 or XCB? - I personally used XCB and didn't find it too difficult to interface with, and there are a large number of implementations which use it (2bwm, bspwm, ratpoison, etc) so you shouldn't have an issue with learning more about it. But the documentation is pretty limited. If you are just wanting to write a toy WM than X11 is perfectly fine.

X or Wayland? - If you're wanting to write your first WM as a hobby project than I would recommend X over wayland just due to the much larger amount of reference material and documentation. You will have a much easier time getting your feet wet. Ignore the comments about X dying as it doesn't really matter for a hobby project, since the whole point is to have fun.

Feel free to check out my window manager which is an example of what just reading this blog post and getting inspired can result in: https://github.com/cfrank/natwm