Brush History

The brushes dock now has a new “history” tag. It keeps a history of the brushes that you used, from most to least recent. It is meant to let you go back to previous brushes, like in other programs. It doesn’t keep a history of every single change you made to your brushes along the way.

When you delete a brush, it is now still available to be undeleted from the history. The same goes for brushes you request from other users, they now get added to the history as “unsaved” brushes. You can’t change the tag assignment or overwrite those brushes while they are deleted or unsaved, you have to undelete or save them first to do so. Removing those brushes from the history deletes them permanently, you will get appropriate warnings about this.

You can also clear the entire history at once from the drop-down and context menus while the history tag is selected. The confirmation dialog will tell you how many brushes you’re about to lose permanently if there are any deleted or unsaved ones.

Work In Progress Project Playback

Some work has gone into implementing playback for project (dppr) files. This is still a work in progress with not much to show for it yet, but there’s been some considerations about how it’s going to work and be architected.

I’ve went back and forth on whether the playback dialog should play things back in a separate window or on the canvas itself, like the current playback dialog does. The former would make some things easier by not having to change the entire reality of your main window into “playback mode”, but it has too many downsides with regards to functionality. It would require implementing half the main window to make it usable, so I’ve ended up deciding against it.

The current playback dialog is pretty old and hasn’t gotten much love in a long time. It will probably just go away and be replaced with the new one, Drawpile can just convert dprec into dppr files when you open them. This allows getting rid of a large amount of code that only exists for the sake of playback, in particular the “index” files that let you jump around in recordings have a large amount of code that makes no sense to continue maintaining, nor does the “companion file” approach work properly on Android, the browser or in Flatpak on Linux. The dppr format on the other hand uses snapshots of the canvas for autorecovery and saving in general already, so the playback can just make use of that.

The functionality of the playback dialog will probably stay largely the same: playing, pausing, stepping forward, stepping backward, changing playback speed and giving you a slider to go to specific points in the recording. The backward stepping ideally shouldn’t be limited to the presence of an index anymore, it’s better to let you jump to points in the recording very slowly than making you rewind all the way and go to the desired spot by manual playback. It would probably make sense to automatically create an index during playback, maybe while showing you the current size of the file and giving you the option to disable the indexing.

What would also be nice is to let you bring back the concept of “markers” that the dprec format previously had. Those didn’t do anything except stop the playback when they happened and I don’t think anybody really used them, given that I have not heard anyone ever mentioning anything about their removal several years ago. With the new timelapse functionality though, you could use these markers to define start and end points as well as crop areas. This would let you sensibly make timelapses of only a part of a session while accounting for multiple drawings being put in the same spot and/or getting moved around along the way, without turning the timelapse dialog itself into a bootleg video editor. The playback dialog can give you a “make timelapse” button of course.

Not sure whether the video export in the playback dialog itself will continue to exist, currently tending toward “no”. It makes more sense to me to first edit the recording and then make a video of it than “doing it live” like the current playback dialog does and if you make a single mistake you have to start all over from the beginning. Separating it has no downsides for any use case I can think of.

Lastly, the missing functionality of letting you open multiple recordings probably won’t be in this dialog either. Instead there’ll probably be a separate way to combine multiple dppr files into a single one first. This is kind of necessary in other cases anyway, for example when you want to recombine a recovery file with a saved dppr file or other situations where you somehow end up with multiple dppr files that are really supposed to be one. So giving you a dedicated project recombiner makes more sense to me than trying to juggle playback across multiple input files. And of course the playback dialog could send you to this combiner feature, like it could for making timelapses.

Minor Additions and Bugfixes

The layer pick shortcut (Ctrl+Shift by default) now shows the name of the current layer on the cursor so that you don’t have to look back and forth between the layer list and the cursor to see what you’re selecting. As a side-effect, also lets you tell which layer you are on currently if you just hold the shortcut without clicking. This was suggested by Gabr.

The line and gradient tool now snap the angle relative to the view rotation when you hold the constrain shortcut key (Shift by default.) This was reported by Ben.

Drawpile will now properly restore the Untagged tag when you open a new window while having that tag last selected, rather than reverting to All.

All that’s described here is available in the alpha release.

Animation Additions

There are two new actions in the animation timeline. One of them is decloning key frame layers. This will duplicate the layers of any key frames that have the same layer assigned. If you previously copied a key frame and it’s now referring to the same layer as another one, this lets you break that reference and have them refer to different layers so that you can edit only one of them.

The other new action is pasting decloned layers. This has a similar effect, but when pasting key frames, it also duplicates the associated layers if necessary. It will not duplicate layers that aren’t assigned to anything, so if you cut and paste key frames like this, you don’t end up with pointless dupes. If you paste multiple key frames, it will retain any clones within that set of key frames and only duplicate them once.

On Android, you can now export videos using the operating system’s video encoder capabilities. Depending on your device, fast hardware encoding is also available, although that’s not used by default because some of them have weird constraints on resolutions or framerates and from my testing they’re hardly any faster for it. Thanks to Bluestrings, hpar and marddle for testing this. This feature is also making its way into Krita, you can take a look at the thread on testing it in their forum.

Also, the WEBM export on desktop now uses a proper quality setting. Previously it could often end up with some pretty hefty compression artifacts due to the maximum bitrate being set excessively low.

Fan Filling

The lasso fill tool got renamed to shape fill tool because it now has two shapes: lasso and fan. The lasso option works like it did before, which is basically the same as the lasso selection does.

The new fan option will instead never make any holes in the shape, instead always filling from the starting point to where you are drawing. That kind of tool exists in some vector drawing programs, probably named after triangle fans that you see used in 3D graphics. This is also how it works under the hood in Drawpile, although usually the triangles are so close together that you don’t see their edges.

This was suggested by lan700ng on GitHub and some more information taken from VolutBrum on the Krita forums.

Stroke Directionality

MyPaint brushes should now interpret the direction of a stroke at the beginning of it better. Previously they could sometimes punt to it being angled at zero degrees and then suddenly jump to the actual direction. This was reported by tiar.

On the other hand, MyPaint brushes that don’t require a direction should now put down their first dab even if you just make a tap instead of requiring you to move a little bit. This was reported by dAVePAGE.

In the tablet preferences, you can also now toggle whether you want Drawpile to start a stroke immediately when you press down your stylus. This doesn’t happen by default because the pressure value at the beginning of a stroke is often unreliable and jittery, so normally you don’t get any input until you move a bit or lift your stylus. Depending on your hardware, turning this off may feel better though.

Minor Additions and Bugfixes

Key frame properties are now properly saved to dppr files, previously it could error on saving. This was reported by marddle on Discord.

On macOS, the preferences now call the Option key by its proper name, rather than calling it Alt. It’s really the same key, they’ve just been historically called different names on PC and Mac. This was reported by Axocrat on Discord.

You can now hit Enter on a numeric input twice to accept the enclosing dialog, rather than being trapped in a loop of editing and not being able to close the dialog unless you use your mouse or tab away to a different control. You can also press Shift+Enter to always close it and Ctrl+Enter to always enter edit mode. Not sure I like how this feels though, it may change again.

You can now configure the default save file name in the preferences. It lets you input placeholders for the current date and time, in case you want a different format or something. This was suggested by Bluestrings on Discord.

Everything here is available in the alpha release right now.

Frame Multiselection

You can now (finally) select multiple frames on the animation timeline. If you have a keyboard to do so, you can hold Shift or Ctrl to do so. If not, there is a new mode you can pick where dragging across the timeline will select and deselect the range.

Selecting multiple frames lets you move those around, copy, paste, delete, assign a color to them etc. The exposure mode that lets you adjust the space between key frames still exists, since it’s convenient in many other cases.

The previous behavior of holding Shift and pressing the arrow keys to move around on the timeline while staying within the timeline range has been moved to Ctrl, since Shift is taken by selecting stuff.

Right-Click Drawing Configuration

Since defaulting it to drawing with the background color has shown itself to be annoying for some people, there’s now options what should happen when right-clicking with the freehand and eraser tools: doing nothing, drawing with the background color or erasing. The default is to do nothing, as it did it 2.3.0 and earlier. You can configure this through the tool preferences or via the hamburger menu in the brush tool settings.

If you assign a canvas shortcut to the right-click, such as color picking, that will take precedence over right-click drawing, as it did before.

This was suggested by noelle and walnut on Discord.

Layer Selection Shortcuts

You can now assign keyboard shortcuts to selecting layers by their color marker. Pressing the shortcut will select the next layer marked with that color, spinning through them if you have multiple.

Relatedly, the select above/below actions in the layer menu are now called select layer above/below in the shortcuts dialog so that you have a chance of finding them.

This was suggested by anonymous on IRC.

Minor Additions and Bugfixes

Exporting an animation now lets you pick a fractional scaling value, in case you need to hit a specific resolution.

Repeatedly moving a transform should no longer sometimes scale it by one pixel. This was reported by Hermanni on Discord.

Android now properly supports stylus barrel rotation, at least on Wacom Artist styluses. Previously it would transmit the tilt orientation as the barrel rotation, which was incorrect. This was reported and tested by kwh0209 on the krita-artists forum and has also gone into Krita.

If Drawpile on Android is terminated due to resource exhaustion, it will now tell you that this happened when you next start it. This lets you tell apart running out of memory from a crash, since annoyingly they look pretty much the same on Android with the application simply poofing out of existence in front of you.

There’s a new workaround in the tablet preferences to prevent full-pressure blotches on Ugee tablets on Android. They have an extremely weak pressure response, but will randomly transmit a single event at 100% pressure. This option will filter those out. It is enabled by default on Android and the browser, which shouldn’t cause interference, since normal devices don’t jump from a really low pressure to a really high one so abruptly. This was reported by London on Discord.

Everything else described here was added afterwards, you can get access to it already through the alpha release.

Beta Release

Drawpile 2.3.1-beta.1 has been released last week.

• The release announcement is at https://drawpile.net/news/release-2.3.1-beta.1/
• An illustrated guide of the changes is at https://docs.drawpile.net/help/common/update2x3x1
• Downloads are at https://drawpile.net/download/#Beta

A few more fixes have made it in before that: unsetting default layers now works again, frames on move-locked animation tracks now don’t block the exposure tool, the small-screen mode tabs on the sides now get sized more reasonably (thanks CosmosX007), hidden layers in frame view mode now behave consistently (thanks hipofiz) and the timelapse dialog is now sized more appropriately by default.

Windows Thumbnails

On Windows, DPPR and DPCS files now have thumbnail support in the Windows file explorer. This is automatically wired up if you install Krita through the Windows installer.

This was developed and contributed by cow.

Touch Actions

You can now assign any action to touch tap inputs, similar to how it works with canvas shortcuts. You can do so under Edit → Preferences → Touch by choosing “Trigger Action” for the touch tap inputs and then picking whichever action you want for them.

You can also now assign things to double-tapping with one finger. This is not assigned by default, since it can delay touch drawing.

For convenience, mirroring and flipping the canvas is also available from the drop-down for tap shortcuts, since those are pretty common actions.

This was suggested by Bnuuyman on Discord.

Minor Additions and Bugfixes

Ratchet rotation now works properly again when the canvas is mirrored or flipped. This was reported by Bovy.

The default filename now correctly uses months instead of minutes. Qt flips around the meaning of m and M formats from normal strftime formatting for some reason. This was reported by hipofiz on Discord.

You can now drag the initial point of a bezier curve again to make it curved instead of straight. Unlike before, it now also previews properly. This was reported by Astre on Discord.

Drawpile should now work on Android earlier than 8 again. This was reported by freyalupen.

Drawpile’s git repositories have also been mirrored to Codeberg now at https://codeberg.org/Drawpile. You can create issues and pull requests there if you wish, but it’s just another place for it, rather than putting everything into only GitHub that has been going down a lot in recent times. I’ll probably also look into having the Drawpile organization join the Codeberg e.V., since they are also an organization “for the public good” in Germany.

Autoresume

On Android, Drawpile will now automatically resume the last autorecovery file. This is because Android likes to silently terminate applications while they’re in the background, giving you no way to decide whether you want to save or discard the current file. This resumption only happens if there’s only one candidate and resumption is only attempted once to avoid getting into a crash loop where the file being resumed runs your device out of memory or something.

If you don’t want a file to get resumed, close Drawpile cleanly via File → Quit or by pressing the back button. Or disable autorecovery I guess, then there won’t be anything to resume either.

Initial Layer Selection Correction

If you don’t set a default layer in a session, Drawpile will now pick the bottom-most visible non-group layer. This is a much more predictable behavior than what it did previously, which was to select the newest layer. This would often enough land you on someone else’s shading layer or something.

Of course an even more predictable behavior is to explicitly set a default layer in your session instead, which works as before. Well, except now you can also now properly unset the default layer again. Previously it would just balk about an invalid layer id.

Sessionlessness

Server owners can now configure a time limit for how long users are allowed to loiter outside of sessions using the sessionLessClientLingerTime server setting. The most common case for this is before they join or host a session, but it can also happen after their session ends and they haven’t disconnected yet because their network is slow or something. By default, this setting is disabled, as it was before.

The web admin UI has been updated to version 0.14.0 in this regard. It also now shows since when a user doesn’t have a session in the users page and notes that any settings that relate to time spans are in seconds unless another unit is specified.

Relatedly, the bug where sometimes users would not get notified that their session got terminated and seemingly remained connected should be fixed now.

Minor Additions and Bugfixes

Properly preview lines, curves etc. when using a brush with smudging. This was reported by retarj_o_burro on Discord.

When reconnecting to a session, the previous save file name is remembered now. This is especially relevant on Android, where the OS doesn’t let you overwrite existing files. This was reported by tiar.

Provide a better default file name instead of just “Untitled”. It will have the current date and session title if you were connected to one. This was suggested by tiar.

The automatic switch to frame view mode when you interact with the timeline now works even if the timeline is not in a tabbed dock. Previously the absence of a tab would cause the timeline to incorrectly be recognized as hidden.

Fixed an issue on some Android devices where you would get disconnected from the session on the first attempt. This seems to have been some bug where Qt’s WebSocket handling would stumble over itself if handling a single message took long enough for it to receive more data asynchronously or something. Just queuing up the handling seems to have fixed it, the same kind of thing is done in the web browser where the asynchronousity of WebSockets could cause a different kind of overlapping mayhem. This was reported by Bluestrings.

The strokes preview in the brushes dock now limits the size of the brush to avoid them from turning into single-colored rectangles, which aren’t useful for spotting the brush you’re looking for. The preview in the tool dock still works as before, since it doesn’t have the concern of wanting to find a brush by sight. This was suggested by tiar.

The text in the brushes dock is also now the proper size on Android. Previously it ended up with a much larger size than the rest of the application for some reason. This was reported by tiar.

Fixed some cases where you could end up with the Session → Host action and the Host page in the start dialog to stay disabled even though you weren’t connected to a session. This was reported by tiar.

Autorecovery and dppr files now sort of work in the browser version of Drawpile. Still, it is disabled by default, since the files can’t actually be stored on disk in the browser and are likely to fill up memory instead.

Stabilizer Velocity Adjustment

You can now adjust the time-based stabilizer according to the speed of your stroke. By default, it is set to reduce the stabilization amount when you move the cursor more quickly.

The effect of this is that the stabilizer won’t lag behind your cursor as much, even at high stabilization levels. It will instead follow a faster-moving cursor at a faster rate, which feels much better and should reduce the amount of fiddling you have to do with turning the stabilizer up and down.

You can disable and adjust the velocity adjustment in the stabilizer menu and the dialog that you can conjure from there or via Edit → Input Settings. Like the “finish strokes” option, the velocity setting is a preference, not attached to individual brushes like the stabilizer amount is. These settings really adjust the “feel” of the stabilizer and I doubt you’d want that to be different for every brush. It should always feel the way you like it, just apply at different strengths.

The default settings probably need some further adjustment. They feel pretty good I think, but only the lowest 10% or so of the velocity curve ever gets hit because you just can’t move your cursor any faster, so editing seems nonsensical until you realize that most of what you’re looking at doesn’t matter. There’ll also probably be more input settings added to that dialog in the future, a lot of stuff from the tablet preferences would be nice to have in a dialog that doesn’t cover up the canvas and block inputs to it so that you can actually try out the changes on the fly without having to constantly open and close the dialog.

Thoughts on Filters

Incidentally, there were several discussions in a few different places about filters in Drawpile. For example, HSV/HSL/HCY adjustment, blur, gradient maps, grayscaling etc. Since it came up so much, it did stick in my mind for a bit and I’ve done some thinking on them.

There are a few different ways One kind is the filter you apply destructively, it will basically cut pixels from a layer, edit them and then paste the changed pixels back. Then there is a few different ways to do non-destructive filtering in different programs: filter layers, filter masks, adjustment layers, correction layers and layer styles. But really, the overarching thing is a filter layer. Filter masks are just filter layers clipped to the layer below. Adjustment layers are just a subset of filter layers that only need to look at pixels individually, similar to a blend mode with extra parameters. Correction layers are the same thing, just translated badly. Layer styles are… kind of a grab-bag of assorted stuff, but some of them are basically filter masks.

In Drawpile, the obvious problem with all of these is that they affect the entire canvas by default. For destructive filters, this is kind of easily fixable: require a selection to apply them. The gradient and transform tools already do this successfully. This could even be implemented without any changes to the protocol, just by literally cutting and pasting the image, with the downside of this being kind of wasteful on the amount of data it requires to transmit and no separate permissions being possible.

The more interesting case would be non-destructive filter layers. Thinking about them a bit, you can kind of do the same technique with them: instead of applying them across the entire image, they can use the layer’s contents as a mask. That way, you can specify which parts of the canvas they apply according to which pixels are filled. Since the color channels are otherwise unused, this could even allow for per-pixel parameterized filters. As a contrived and probably not very useful example, a HSV filter could use the red, green and blue channels of each pixel as inputs for the hue, saturation and value adjustment.

The other problem with these layers is performance. You can see this in Krita: something like a blur layer is extremely slow. They are so slow that they have to get updated asynchronously, with a progress bar on the layer showing you when it’s going to be done. This is kind of inevitable: regular layer compositing just happens to each pixel individually and can be parallelized, but something like a blur has to look at surrounding pixels to do its job, which obliterates performance.

However, like I said above, some filter layers only affect individual pixels. A blur filter is really the worst-case example because it needs to span across the entire image, but a HSV adjustment or gradient map can be applied to every pixel individually in parallel, like a blend mode. And Drawpile even already has blend modes that do stuff like this, like Hue, Saturation or Color, so we know the performance is acceptable. And we don’t even need to reinvent a new term here because other programs already given this subset of filter layers a name: these are adjustment layers!

So this may be a way to get these kinds of non-destructive filters into Drawpile, with stuff like blur and more complicated filters left out for now. It definitely would require a protocol change and so won’t happen in 2.3.1, but the idea seems sound to me.

Minor Additions and Bugfixes

The brush editor now sorts its entries into logical categories instead of having them all in a big list. This was suggested by Blozzom on Discord.

Brush preset data and thumbnails are now loaded on demand, which makes startup, switching tags and other operations that reload brushes much faster.

Searching for brushes no longer changes which brush you have selected if the current brush gets filtered out.

The invite dialog now tells you whether joining via web browser is restricted or not available. This was suggested by Bluestrings on Discord.

You can now skip around in the playback dialog again after creating an index file. Previously it failed to load the index because it always thought the canvas size was invalid. This was reported by Saova on Discord.

This might be everything that needs to be done before translations can be opened for a beta release, although I’ll wait another bit in case there is feedback or I can think of something else.

More Autorecovery

Some more touchups have been made to autorecovery to get it ready for release. It is also now enabled by default.

The autorecovery settings dialog can now be summoned even when autorecovery is not active and lets you manage autorecovery settings for the current session there. You can enable and disable the autorecovery as well as change the size limit. It also has a link to the autorecovery preferences (which in turn have a link back to the dialog.)

At the bottom-right corner of the status bar, there’s now indicator for the autorecovery status. It will show a backup symbol when active and a crossed-out symbol when not. You can click on this to open the autorecovery settings. Previously, this spot in the status bar had a lock indicator icon, but that had become pointless now that the locks are displayed as a message on the canvas instead.

In the start dialog, there’s also now a message telling you if you have files to recover.

Synchronized Smudging Speedups

Synchronized smudging is a feature on brushes that will make the brush wait for its own stroke before it picks up colors from the canvas. It’s enabled by default for MyPaint brushes, since many of them rely on this being accurate or else they’ll produce artifacts. On the other hand, this is slower of course, because waiting takes more time than not waiting.

The main speedup has been to no longer send the strokes through the main thread, they are now sent directly from the stroke thread to the paint engine. This makes a huge difference on some devices where for some reason the main thread is slow at picking up the work. Well, relatively slow, it still takes less than a millisecond, but that adds up when the brush does a lot of smudging. On other devices that were fast to respond to begin with, you will probably not notice any difference.

When you make a stroke while another one is still going, that one is now cancelled after a moment. This stops strokes with really slow brushes from taking forever with no sensible way to cancel them and also fixes a hang that could happen if you switched brushes too quickly and started a non-synchronized stroke while a synchronized one was still going, which would get stuck forever waiting for each other.

The brush engine also now no longer pointlessly waits for the stroke if it didn’t change anything on the part of the layer that it wants to pick up colors from. This can happen with brushes that put down totally transparent or infinitesimally tiny dabs or brushes that have significant jitter. On brushes that just draw a line, every new dab will overlap with the last one, so this won’t make a difference for them, but those usually also do less color pickup to begin with.

Finally, MyPaint brushes that have an insignificant smudge factor set and don’t explicitly enable or disable synchronized smudging now default to having it disabled. It doesn’t make a visible difference anyway due to how little the smudging affects them, so I suspect that they have a smudge factor set at all is unintentional to begin with, whoever made the brush just didn’t fuss with the setting after they were happy with how it worked. A few of the default brushes in Drawpile are affected by this, as well as some in popular brush packs.

Passworded Session Improvements

While it has become pretty rare, it still happens occasionally that people will unintentionally host a public session when they mean to host a passworded one. This sometimes causes them to panic because strangers join their sessions and they end up kicking them or asking for server admin support. There’s been some changes to hopefully make that better.

The host dialog now always defaults to the passworded setting, even if you had it set to public last time. This is simply a safer option, it’s easy to forget that you had things set differently three weeks ago and not notice that you’re hosting a public session until you suddenly have strangers joining.

The text for the public and passworded sessions has also been changed. “Public, anyone can join” is now called “Public, strangers can join” instead, since people may have thought that they needed this option to let people without an account join or something. “Personal, only people you invite can join” is now just called “Only people you invite can join”, since the “personal” just adds a chance for misinterpreting what that means. There was some mulling about calling it “private” instead, but that would inevitably be confusing when you’re hosting on the public servers.

If you try to host a public session without setting a title, you now get asked whether you want to continue with a passworded session instead, rather than just giving a generic error. If you try to host a passworded session without a password, Drawpile will automatically generate one instead of balking that you didn’t specify one. These are basically just shortcuts, rather than making you do this stuff manually.

The invite dialog will now show a notice that you’re hosting a public session. If you’re an operator, you also get a prompt to set a password. So if you somehow hosted a public session on accident, you now have a way to immediately fix the situation instead of only noticing when strangers start streaming in. The dialog also now has a button that takes you to the session settings, since it’s a somewhat common place to want to go after starting a session to do more setup.

When you change the session password in the session settings and just hit OK with no password entered, you now get a warning that this will make your session public. This gives you a chance to back out if you didn’t actually mean it.

Lastly, the operator password setting in the session settings has been moved to the roles tab, like it is in the host dialog as well. There’s been several cases where people confused the two password options in a stressful situation and accidentally set an operator password instead of the session password, which obviously did nothing to stem the flow of strangers joining.

Obviously all of this doesn’t stop people from intentionally hosting a public session and just kicking everyone except their friends when they join, but that’s hopefully rare. It would be possible to detect that kind of case and automatically set a password on the session, but that would inevitably be prone to false positives.

Thanks Bluestrings, Hyper, tiar and watt for discussions and ideas here.

Block New Joins Removal

The “closed” flag has been removed from sessions. In the client, this was called “block new joins”. What this feature did was to prevent anyone else from joining… which you can achieve just by setting or changing the session password.

The way this feature gets used is basically just a bootleg password anyway. People host a public session, let their friends join, then block new joins. If a stranger joins, they get kicked and may report the session, which is annoying for server admins. If someone gets disconnected, the setting has to be changed again because they won’t be able to rejoin. If everyone is away, they have to annoy server admins. And after everyone leaves, the session becomes public again, which may unexpectedly expose their pseudo-private session to everyone until it expires.

Setting a password has none of these downsides, you don’t need to constantly set and unset it, you don’t get locked out from rejoining and your session doesn’t become public after everyone leaves. And even if you for some reason really want your friends to join without a password, you can still unset and then reset the password, so you can still run sessions in this weird way. If you want to lock people out after they leave, you can just change the password.

So as far as I can see, removing this feature doesn’t remove anything useful, it just gets rid of a feature that annoys server admins. Newer clients will simply not show this checkbox if the server indicates that it doesn’t support it. Older clients will get an alert that the server doesn’t support it and to set or change the password instead.

Minor Additions and Bugfixes

On Android with Huawei styluses, a double-tap gesture is now translated to the F25 key. This was reported by noalero on the Krita Artists forum and has also made it’s way into Krita.

Using anti-overflow with a non-zero expand value set will no longer have a chance of crashing when drawing at the edge of the canvas. This was reported by Ausjamcian.

The simplified brush preview now shows the highlight color for brush that smudge (blue in the default theme) and a checkerboard for erasers. This was suggested by Blozzom and issues reported by xxxx.

The files preferences where you can toggle the debug log now has a button to let you clear all log files. This is particularly useful on Android where you can’t delete them manually, although it’s pretty unlikely that some text files are going to be using a measurable amount of space.

Changing the timeline range on one side of a timeline that has no range set will now properly set both ends. Previously it only set one and extended the frame count until you changed the other side as well. This was reported by dAVePAGE.

When loading an ORA file without timeline information, the timeline now properly loads with a range in it, rather than just being confined to 1 to 24 frames.

I think this is getting pretty close to a beta release. There are still some things I want to change before opening translations, but the big feature of autorecovery should mostly be ready enough to be worth it, especially for people who use Drawpile offline and don’t have a safety net of their drawings being in an online session.

Autorecovery Limits

Autorecovery files now have a limit you can set in the preferences to prevent them from getting overly large and eating up all your disk space in pathological situations. For example, if you idle in a public session for days on end with autorecovery enabled, the recording can get unreasonably large. The same goes if the session is manually reset many times, each of those resets adds quite a lot of size to the recording.

Since this limit is just supposed to be a safety net that is never supposed to be hit in practice, the limit is quite high by default: 5 GiB on desktop, 1 GiB on Android and 500 MiB in the browser. You can configure it in the preferences and you can also change it for individual sessions under File → Manage Autorecovery. Autorecovery files are temporary and get removed upon quitting Drawpile cleanly, so they won’t eat all your disk space while not using the program. These limits should be high enough to even record a large multi-user animation project in one go without losing any data, any normal session will be far below that.

When a file hits 75% of the limit, you will get a warning above the canvas. If you keep going and the limit is hit, autorecovery will terminate for the current session.

Project Compression

When you save to a dppr file, the drawing commands saved to it are now combined and compressed. It uses a similar compression to the pixel data.

From my testing, this can make files 70% smaller if you use particularly egregious brushes. But even realistic often end up half the size of what they were before, without any measurable slowdown when reading or writing the files. You can check the differences yourself by saving to a dppr file and then comparing it with the uncompressed autorecovery dppr file in Drawpile’s application data directory.

The autorecovery files are also in the dppr format, but are not compressed like this because that would require buffering many commands in memory before writing them out. That obviously goes against the point of the autorecovery feature, if it’s all just in memory and your power goes out, you can’t recover it.

More Move Locking

Continuing from last week, key frame move locking is now fully implemented. It has its own icon, you can drag over the locked track to flip through the timeline and using the exposure tool will ignore move-locked trackes, letting you change the exposure on tracks that aren’t adjacent to each other.

The actions that previously increased and decreased the exposure of all visible tracks now ignore the move locked ones instead, since that makes more sense.

Minor Additions and Bugfixes

When you enable long-pressing for context menus, the canvas is now no longer considered to have a context menu. This fixes some cases where the long-press emulation interfered with other interactions.

Sliders and numeric spinners now ignore slight adjustments made immediately before letting go of them. This should fix the annoying issue where you lift your stylus after carefully adjusting a slider to a value and then the slight jitter causes it to get nudged off the desired value.

Text input on Android has been rewritten to a large degree. Hitting spacebar on a physical keyboard should now work as a shortcut again without your keyboard application eating it, the view should no longer turn blue on some devices when pressing a key and text inputs should no longer curse the area of the screen they were on and prevent stylus inputs. All of these only happened on certain devices. This also made it into Krita 5.3.1 already.

On Android, F13 to F24 keys are now handled properly. F21 is translated to middle mouse button by default, which you can toggle in the preferences. This is a workaround for OnePlus styluses, which inexplicably input this key when you press their stylus button, despite Android having perfectly functional stylus button events they could be using. This was reported by Clover_Yan on the Krita-Artists forum and is also part of Krita 5.3.1.

Transforms with oversized selection masks now properly get translated to a cut and paste operation. This was reported by phanie on Discord.

When you disconnect from a session where you aren’t user 1, save the file and then open a file or new document, you no longer end up in a weird situation where you are simultaneously user 1 and whatever other number you had before, which caused permissions to get really loopy and your own strokes to show a user marker on the canvas. This was reported by grimsley on Discord.

Autorecovery Renaming

The “autosave” feature is now called “autorecovery” because that probably describes better what it does and separates it from the previous actual “autosave” feature where Drawpile would basically just periodically hit Ctrl+S for you. From seeing issues with that kind of thing with Krita, many users associate that exact behavior with autosaving, so it’s a better idea to use a different name I think.

It still doesn’t really describe fully what it does, since you also need to enable autorecovery to get timelapses and project statistics, but it’s probably close enough.

Spinner Sliding

You can now drag over most numeric inputs in Drawpile to adjust their value. This makes them less annoying to input without a keyboard. As a side-effect, you can also now enter math expressions into them (like you can into sliders too.)

I still find that it often changes the value while lifting the stylus, since that naturally introduces some jitter. That can probably be solved by adding a bit more drag resistance if you held the cursor in a single position for a bit.

This was suggested by LingjenKaos on the Krita-Artists forum and may make it into Krita if it has positive reception in Drawpile.

Timeline Exposure Tool

The timeline now has an exposure “tool” that lets you drag to increase or decrease key frame exposures. This basically makes the timeline usable if you don’t have a keyboard to change exposure and it’s also more comfortable and performant than repeating the same action. You can also access this by holding the Alt key.

Dragging across a single track changes the exposure of that track, dragging across multiple tracks changes it on all within the range. Dragging over the header changes the exposure across all tracks.

Timeline Zoom

The timeline can now be zoomed. This makes the key frames wider or narrower horizontally.

You can also zoom it by holding Ctrl and spinning the mouse wheel.

This was suggested by Myathingoss.

Key Frame Move Locking

You can now lock tracks for yourself to prevent accidental moving of key frames. This is useful when you’re in the coloring stage for example and definitely don’t want to be throwing frames out of order.

This feature isn’t fully baked yet. The icon definitely needs to be different, since a lock is too strong of an indicator. It also probably should let you drag over the key frames like you can over the header instead of doing nothing at all. The exposure tool should probably also ignore move-locked tracks, which would let you move multiple tracks at once without them having to be adjacent. Feedback on this would be appreciated.

This was suggested by Saphiros.

Flipbook Looping

“Reverse” ranges in the flipbook will now play back everything outside of the given range.

That is, when you for example have an animation that goes from frame 1 to 100 and you enter a range from 90 to 10, it will play back frames 1 to 10, then skip to 90 to 100. This is useful if you’re making a looping animation and don’t want to keep watching the entire thing all over again if you’re working on the looping bit.

These ranges don’t export correctly yet. This was also suggested by Saphiros.

Minor Additions and Bugfixes

The track controls on the timeline are now above the tracks in the area that was previously just a blank space. This saves some room in the (still very wide) docker header.

Deleting a key frame that is only assigned to a single layer now also deletes the associated layer by default, since that’s probably the more common desire than leaving a stray layer laying around. Unlinking a key frame is now a different action.

The short settings page now has an “overview” tab that explains the different flavors of shortcuts. It seems like the tabs at the top often got missed when users were searching for e.g. a way to rebind a canvas shortcut, so this hopefully makes that better.

The main menu bar actions (File, Edit, View etc.) can now be assigned to action shortcuts, by default they are on Alt+F, Alt+E etc. like before. They’re no longer dependent on the language you have Drawpile set to.

In that regard, hitting Alt on its own will no longer cause the main menu bar to steal your keyboard focus.

Brush Preview Options

There’s now different options for the brush preview in the brush settings dock. You can toggle showing the thumbnail and a title, as well as choosing between a plain and the full preview. You can also disable the preview altogether. These options are in the top-left menu of the brush settings dock.

The default is now the plain preview, since I think the full preview with its checkerboard and many colors is a pretty annoying thing to have in the corner of your vision. The plain preview is significantly calmer and still shows the most useful aspects of a brush.

I’m still not fully happy with this preview, since it fails to represent some important aspects, in particular erasers and smudge brushes. Erasers could maybe be shown via a checkerboard pattern, with some trickiness with regards to partial erasers that MyPaint brushes can be. But for the smudge brushes I don’t have any ideas for how to represent it without making the preview look noisy again or popping up extra elements that cause confusion by being present. This was a past problem of the preview, where it changed a lot depending on which settings you toggled and users just got distracted by the background changing instead of actually seeing what modifying a setting does. If you have ideas on this, let me know.

Brush Stroke Previews

In a similar vein, the brushes dock now gives different display options: thumbnails, strokes or both. The default is now both, since I think seeing the name of the brush and what the strokes look like is worth the trade-off of it taking extra space. The style of the stroke previews is always plain, since the full preview would not only be garish, but also very slow.

The thumbnails display option also spreads the thumbnails out across the available horizontal space instead of pressing them against the left side and leaving a gap on the right.

You can also adjust the size and amount of columns of the previews. These options are available in the top-left menu of the brushes dock.

Curve Inputs

Curves for brush inputs and similar now have input fields that show you the X and Y values of the currently selected point. You can type into them to reach precise values.

FFmpeg Exports

The animation and timelapse exports now allow you to use FFmpeg to export to some additional formats that aren’t included with Drawpile for space or legal reasons. FFmpeg is a video encoder that you can get separately, on Linux you’ll often already have it installed because a lot of stuff uses it.

In particular, MP4 video with the H.264 codec is very useful, since it is fast to encode and very compatible, but can’t be included in Drawpile because of legal issues in some countries. There’s also AV1 and APNG, which are useful in rare cases, but not worth shipping with Drawpile and increasing the amount of dependencies and the size of the program for.

This is not available on Android or the browser, since those can’t run an external programs.

Minor Additions and Bugfixes

The timelapse export should now handle canvas resizes properly and put the correct color on the outside when the video aspect ratio is different from that of the current frame.

The clipping and alpha lock controls on layers are now properly enabled when switching from a non-editable to an editable layer. This was reported by xxxx.

The alpha inherit icon now properly changes color when switching themes. This was also reported by xxxx.

Brushes with out-of-range inputs no longer get clamped by the mere act of opening the brush editor. This was reported by Phoneme.

Repeated frames are now repeated instead of held when exporting videos for timelapses and animations. This is a little slower, but avoids videos getting cut short at the beginning or end by misbehaving players or video processing on art sharing sites.

Brush thumbnails are now only actually decoded when they need to be displayed. This should speed up startup if you have a lot of brushes.

On Android, additional stylus or mouse buttons beyond left, right and middle are now handled properly. This makes e.g. the Wacom MovinkPad’s stylus work correctly, whereas before two of its three stylus buttons got interpreted as a middle click. Mouse button 5 is now bound to toggle the eraser by default. This will also be coming to Krita. Thanks Halla for reporting.

The brush outline for MyPaint brushes now uses a consistent size when switching tools. It could end up with a different size in some cases that would then jump to a different one as soon as you changed the brush size.

MyPaing brushes are now properly marked as modified when you change inputs beyond the first one.

The animation flipbook no longer limits the playback frame range to 99 when opening it.

Color selection in the annotation tool is now asynchronous so that it doesn’t crash in the browser. The web client has been patched to include this. This was reported by Curiosity on GitHub.