Skip to content

Add real time capture mode for the recording docker plugin

Real Time Capture Mode

The current implementation of the recorder plugin only allows a minimum capturing interval of 100ms or a maximum frequency of 10 frames per second. This is not sufficient for some use cases where the artist wants to record his drawing in real time.

The new Real Time Capture Mode (RTC mode) fills this gap. To address the performance issues that occur at higher frame rates (20 fps and more), this merge requets refactors the recording implementation. The artist can now configure how many threads to use for the recording. This makes it possible to achieve high rates even if the capturing of a single frame takes longer than the capturing interval.

Additional changes:

  • Refactoring of the export settings to be able to retrieve the Video FPS value from anywhere in the recorder plugin
  • Add the necessary GUI and configuration adjustments for the RTC mode
  • Replace the Capture Interval setting with the Video FPS setting in case, RTC is switched on
  • Add an Input FPS <-> Video FPS locking feature, which syncs these two values (which makes more sense for the RTC mode)
  • Improve the REC status bar: now all available cores and recording threads (distinguished by idle and active threads) are displayed during active recording. This gives the artist a very sensitive feedback whether the desired capturing of the drawing can be managed.

Merge Request Handling

Because this feature is slightly bigger, we should consider bringing this MR back to master by an oldschool merge instead of rebasing it.

Test Plan

The real time capture was tested manually, all new features as well as the existing ones (recording without real time capture mode switched on). My wife has been using the feature productively for over a month now, and I haven't received any complaints so far ;-)

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -> There aren't any unit tests for the existing plugin
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Edited by Florian Reiser

Merge request reports