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

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.

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.

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.
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.
]]>The new timelapse feature described in the last dev update now supports playing back animations. If Drawpile detects that there’s an animation on the canvas, it shows a checkbox in the timelapse dialog to play the animation as the result, which is checked by default if you’re currently in frame view. If the flipbook is using a different range or speed than the global timeline, you also get a checkbox whether you want to use that. By default the animation is played once at the start of the timelapse. You can change that in the advanced settings.
Note that to make use of this, you have to enable autosaving and save your project as a dppr file! To enable autosave on the current session, use File → Autosave. To enable it for new sessions by default, use the options Edit → Preferences → Files. Note that there’s currently not yet any limits on these files, so you shouldn’t enable it if you plan to idle in a public session for a long time.
Here’s an example of this feature, thanks to BulletPepper for providing this.
The flipbook now properly updates its frame range if it encompassed the entire timeline range and you change it while the dialog is closed. Previously it got stuck with its original range unless you kept the dialog open. Refreshing the flipbook also no longer resets the playback to the first frame of the range, it instead keeps playing from the current frame.
The previous “zoom” menu is now a more general menu with settings to reset the frame range and speed manually. There’s also now an action that lets you set the flipbook speed by FPS, letting you enter the desired amount and then setting the speed to match that exactly based on the current canvas FPS.
There’s now new actions in Animation → Next/Previous Frame Within Range, which let you move around the timeline while wrapping around within the frame range. The same also happens when you focus the timeline and hold Shift while pressing the arrow keys.
Most of these were reported and suggested by BulletPepper on Discord.
The user interface scaling method has been reworked on Android to make it easier to pick a comfortable interface scale without having to restart Drawpile a bunch and potentially ending up with an unusable interface size. When you start Drawpile, it will prompt you with a dialog to pick a comfortable scale for the interface and whether you want to use the dynamic, desktop or mobile mode. Changes are previewed on the fly.
The second time you start Drawpile, you’ll also get a checkbox whether you want Drawpile to ask you about the scale every time, which you can uncheck once you’re sure you’re happy with it. It isn’t shown the first time to avoid users unchecking it before even using the program and potentially picking a scale that makes it unusable after all. You can bring the dialog back via View → Interface scale… or via Edit → Preferences → User Interface.
Some issues with font sizing were also fixed, some devices had a wonky relation between the default font size and the rest of the user interface scale. Existing scaling and font settings will be reset, since the new system works quite differently.

Analogously to the pan and zoom tools, there’s now a rotation tool. It lets you rotate the canvas without requiring some secondary action or poking at small interface elements, which can be useful especially if you only have one hand and no keyboard available.
The tool offers the same options as canvas shortcuts do: a regular rotation that snaps around 0°, a free rotation that doesn’t snap and a ratchet rotation that rotates in 15° increments. The default shortcut for the tool is Shift+R.
This was suggested by Cryankiebuillars on Discord.
]]>For the following features, you have to enable autosaving and save your project as a dppr file for this to work! Currently, autosaving is still disabled by default, since there isn’t any limits in place yet and idling around in an online session could lead to very large autosave files.
To enable autosave, use the options in Edit → Preferences → Files. You can also enable autosave for the current session via File → Autosave.
You can view statistics on drawing sessions and times thereof saved in a project file via File → Project Statistics.
This dialog shows you the drawing sessions you’ve had on the project, as well as the times thereof. The open time is when you opened the file and the close time is when you last saved it.
The more interesting time is the work time though, this shows you how much time you’ve actually spent working on the picture, not just having it open. These times are based on the commands stored in the file, measured at a granularity of one minute. This gives a pretty accurate idea of how long it actually took you to draw something, which is useful for setting commission rates or figuring out how much time you ended up procrastinating with Drawpile just being open.
There could probably be more switches for these statistics here, but I couldn’t think of any useful ones yet. If you have ideas, let me know.

You can now generate timelapses of your drawing process (sometimes incorrectly called “speedpaints”) out of project files without having to manually record them or use a separate command-line tool to generate them. The dialog is under File → Make Timelapse.
Here you can configure the size and duration of the timelapse, as well as where you want the Drawpile logo to go, if anywhere. Behind the advanced settings foldout there’s a lot more knobs you can twiddle if you really want to. If you select an area before opening the dialog, the timelapse will be cropped to the selection bounds. Drawpile does its best to keep the cropped area consistent in the face of canvas resizes.
Currently, MP4 and WEBM videos are supported output formats. Exporting a series of PNGs and JPEGs would probably also be nice, especially for cases where you want to do something more complicated with the timelapse and throw it into a video editor.
It also doesn’t yet integrate with the existing recording formats in any way, the reason being mostly that those are just missing all the timing and cropping information that makes timelapses work sensibly. The way to integrate them would be to let you combine multiple dppr project and dprec/dptxt recording files into a single dppr file and then generate a timelapse from that, rather than complicating this dialog by letting you pick multiple input files or something.

You can now assign canvas shortcuts to trigger action shortcuts. For example, you can make your stylus button switch to the eraser or undo or do whatever other action.
The Settings are under Edit → Preferences → Shortcuts, in the Canvas tab. Here you can choose from some common predefined actions, like eraser toggling or undo/redo. If that’s not what you’re looking for, you can also pick “Trigger Action” and choose any other kind of action.
This was suggested by RubySnoot and SOLARIS.

Previews for editable fills now correctly switch to the layer you select, rather than appearing to be stuck on the original layer and then applying to the selected one.
The wonky an slow animations for rearranging docks and toolbars are now disabled. This makes rearranging the UI feel much better I think.
]]>You can now save to DPPR “project files”. These files basically combine the features of DPCS files, which store snapshots of the canvas, with DPREC files, which store demo recordings. That is, they store the commands that are sent and received across the network, not video recordings. These are also the same files that autosaving uses.
When you save to a DPPR file and have autosaving enabled, it will save both a current snapshot and the active autosave recording to the file. If autosave is not active, it just saves a snapshot to it. If you try to save to a DPPR file that already contains a recording, Drawpile will ask whether you want to append to it or replace it.
Currently, opening the file just loads the latest state. But having this combined data allows for a bunch of other stuff that’s being worked on, such as getting statistics on how long you spent actively drawing the picture, generating a timelapse from it or restoring the canvas at any past state.
Drawpile doesn’t yet try to deduplicate the recordings in any way, so the files end up larger than they need to be. For example, if you open a DPPR file and then save to it, it will unnecessarily store a “starting snapshot” from the beginning of the current session, even though that’s unnecessary when it could just continue from the previous session. The same goes for reconnecting to online sessions, it will just save another session instead of continuing a prior one. That’s something I’ll probably try to solve once playback and timelapses are implemented though, since then it’ll be easier to test if removing those snapshots works properly and what extra information may be needed to connect them up properly.
In that regard, under Tools → Developer Tools → Project Information, there’s now a dialog for inspecting the structure of DPPR files. It shows mostly techy information, a proper user-facing project dialog with options to look at statistic, make timelapses and whatever else might follow is in the works.
The autosave recovery page in the start dialog now shows your own work time next to the files, to let you tell which ones are relevant if there’s multiple similar ones.
Drawpile now asks you whether you want to overwrite a file after potentially changing the extension. Previously, when you e.g. saved a PNG or PSD file, it asked you if you want to overwrite it first and then afterwards asked you whether you want to save as ORA or DPCS instead, which would then overwrite that file unquestioned if it already existed. Now it does it the other way round.
On Android, there’s now a workaround for the stylus on Xiaomi devices misreporting historical positions and causing jagged curves because of it. Basically, instead of actually reporting the positions the pen moved along between input frames, it just connects the “real” positions with a straight line and no pressure interpolation at all. The workaround just ignores those intermediate positions and lets Drawpile’s jagged curve compensation pick up the slack. This can be toggled in the tablet preferences, is enabled by default if the device is detected to be a Xiaomi one and is also going to be in the next version of Krita.
Also on Xiaomi devices, there’s a workaround to translate page up and down keys to right and middle clicks. This is because their stylus inexplicably inputs those keyboard keys when you press the buttons on the side. Same deal with the workaround above.
And again on Xiaomi devices, the pressure curve is now steeper by default, capping at 70% to reach maximum output pressure. This is because I found it to be physically virtually impossible to press hard enough to reach 100% input pressure otherwise. This pressure curve, along with a preset for Apple styluses that caps out at 50% and an “anti-strain” option, is available in the global pressure curve preference now.
]]>A bunch has already been written in the last development blog, so I won’t reiterate all of that here. Here’s just what’s in the alpha release as of the time of this blog post.
The previous autosave mechanism, which periodically saved to the previous file you saved to if you enabled it, has been removed. It has been replaced with an “auto-recording” system. Instead of periodically saving, records everything that happens immediately. This should usually let you recover up to the very last brush stroke and is generally pretty light on performance.
Currently, that is also not enabled by default, mostly because there isn’t any limiters set in place. Like, if you have a session running in the background for a week, that could make your autosave file get pretty huge. You can enable auto-recording globally through Edit → Preferences → Files, where you can toggle it separately for hosted/offline and joined sessions. As before, you can also enable and disable autosaving for an individual session via File → Autosave.
You can also change the interval in which Drawpile takes snapshots of your canvas in the preferences. That setting is mostly there so that people don’t ask about it. Snapshots basically just make recovering an autosave file faster, since it can start from there instead of having to play everything back from a blank canvas. The default value of 10 minutes should be fine for most cases, playing back 10 minutes of drawing should take less than a minute even on slower devices.
There’s a recovery page available in the start dialog where you can recover and delete autosaves. Those will save as dppr (“Drawpile project”) files. The only thing you can currently do with them is to open them to recover an autosave, it’s not yet possible to save them, as is getting timelapses or drawing times out of them.
Autosave files are automatically deleted when you close Drawpile normally. If you want to keep an autosave file for testing, you can abnormally terminate Drawpile, e.g. with kill on Linux, ending the process through Task Manager on Windows or force stopping the application on Android.
Testing, feedback and suggestions are appreciated.

Three- and four-finger taps should now work on Xiaomi Android devices. Their operating system has a bug where it cancels those inputs even when you disable those gestures on the system level, Drawpile now ignores the cancellation. This fix has also been ported to Krita.
Stylus buttons on Wacom tablets on Android should now work correctly. Previously they only input a button press when you simultaneously pressed a button on the stylus and put the tip onto the canvas, with the buttons sometimes getting stuck in a pressed state altogether. Now they properly actuate when you press them. This fix has also been ported to Krita.
Drawpile no longer tries to detect whether you have a stylus attached on Android based on what the device says, since at minimum Xiaomi devices just lie about it and always say that a stylus is attached. Instead it now only considers a stylus to be present when it actually sees a stylus input at any point. If you don’t want this auto-detection, you can explicitly pick whether you want touch drawing or not under Edit → Preferences → Touch, just like before. Along with that, the “Guess” option has been changed to say “Automatic (Draw)” or “Automatic (Pan canvas)”, since that makes it clearer what’s going on.
]]>While it still uses the same underlying implementation, the settings interface in the entire application has been swapped out.
The previous interface was based on Qt’s QSettings and had a very nice C++ interface. Unfortunately, like using C++ intensely often does, this has caused problems with the Microsoft C++ compiler in the past, as well as driving up the time it takes to build Drawpile.
The new interface is elegant, using macros instead of C++ templates to bind settings to controls and such. However, this speeds up building the project by about 10%, which is a pretty huge chunk.
The code for the interface is now generated in advance from a definition file, rather than at compile-time, and is able to use different implementations under the hood. Currently it only supports in-memory settings and delegating to the previous implementation, but presumably that’ll be switched to SQLite in the future.
On the surface, there should be no difference. There may be bugs though, since this switch touched a lot of parts of the application.
The work on automatic saving (or really, automatic recording) has been progressing. A good chunk of it is functional now and it might be possible to get that into a state that’s already useful in the coming days (depending on holiday spirit), but another chunk is still missing.
The actual saving part works. That is, when a new canvas is created, a file is opened or a session is joined, Drawpile automatically saves a snapshot and starts recording everything you do to a project file. If you exit Drawpile cleanly, that file is deleted. If not, it is retained and will show up on the start dialog in the new Recovery tab.
Unlike most other program, this autosave mechanism is continuous. That is, it doesn’t save a snapshot of your current state every few minutes, it instead records every drawing command as it happens. The only thing that is periodic is the generation of a thumbnail for the recovery dialog. It probably would also make sense to take a periodic snapshot to make recovery quicker instead of having to do it from the beginning, but that’s not currently done.
That means you can’t just restore the latest state of a canvas, but also every state leading up to it. You could even theoretically edit the recording, for example to fix the old “lined on the sketch layer” situation, if we can figure out a UI for it. It’s also possible to create a timelapse from it and to query how long you’ve spent actively drawing a picture by looking at the timestamps of the recorded commands.
There’s currently two settings to enable autosaving when offline and to enable it when joining a session. When you host a session, it starts out offline, so there’s no separate setting for this, the offline recording simply continues. You can also toggle autosaving on the fly through the File menu.
There probably need to be more settings for this, such as size thresholds. You wouldn’t want a runaway session to eat up all storage after all. It may also make sense to give the option to enable or disable autosaving in the login dialog so that you can decide whether you want it when joining a session. It may also make sense to give the option to manually or automatically truncate recordings for when you don’t care about restoring past states, making timelapses or querying your work time.
I’ve also been thinking that it could make sense to keep autosave files around a little longer, rather than instantly obliterating them when you exit. Of course it would need to be configurable how much space you want to spend on this, but the files are generally pretty small, so even 512 MB would usually let you store a good number of them as a safety net. That way, even if you accidentally press “discard” on the wrong window, you’ll be able to get your pictures back.
Further ideas on this are appreciated, there’s quite a lot of possibilities to this feature.

There’s been some work on the project file format already written about in an earlier blog post. The idea is mainly that Drawpile will automatically record your drawing, serving as autosave, timelapses and more.
The work on that is still going on, but some infrastructure has been built to run this auto-recording on a separate thread. It still needs to be integrated though.
The settings in Drawpile have historically been using Qt’s QSettings implementation to persist its settings. This implementation has several problems: it’s slow, inconsistent between different Qt versions and seems to sometimes get corrupted in strange ways. The slowness even requires some workarounds in Drawpile that make it only actually save the settings when you’re not actively using it to avoid it chugging.
There’s also a very pretty wrapper around the settings, which allows the code using settings to be very clean and concise. Unfortuantely, that code uses C++ and the Qt meta-object system pretty intensely, which has turned out to be a mistake. For one, it causes Drawpile to build significantly slower, by far the slowest files in the entire codebase. And for another, it has caused multiple crashing bugs in the past because Qt just doesn’t expect to be used that intensely.
The solution is, as usual, to use SQLite instead. It’s fast, robust and allows partial writes. Drawpile already uses it for certain settings and it’s also the basis for the new file formats, where it’s showing just how fast it can be. There’s been some work done to start transitioning over to this, but there’s quite a lot of settings to work through, so this isn’t done yet.
New brushes were added (all in the “Drawpile” category):

And some new layouts (accessible through View → Layouts):

The palette in the color picker tool settings will now only fill with colors you actually picked, rather than getting spammed with every color you drag over along the way. When you manually add a color here, it also now defaults to your current foreground color, rather than starting out black.
You can now toggle the sampling ring in the color picker tool settings, rather than having to go into the preferences for it.
The color sampling ring now has extra thickness on the sides to make the color comparison more visible. This is based on an implementation for Krita by tiar.

Code for porting over really old settings from version 2.1 and earlier has now been removed, since it doesn’t work properly anymore and causes more harm than good. This affects moving settings out of the registry into a file on Windows and porting over an older brush preset format that stored the brushes in directories instead of a database.
If you really need this functionality, you can run Drawpile 2.2.2 once to have it do the conversion. However, the program has changed quite a lot since Drawpile 2.1 was released in 2017, so it’s probably better to start fresh than trying to pull in a really old setup like that.
A new feature for the hardware renderer had been added to make zooming look better. That worked fine on most systems, but on some it introduced a lot of slowdown.
It has now been made a setting and disabled by default. This was reported by Bluestrings and Sinamer on Discord.
When you make a selection, a bar will now appear on the canvas, by default in the bottom-left corner. On one hand, this is meant to let you tell that a selection is active so that it doesn’t end up off-screen and there’s no indication why you can’t draw anything.
Another reason is to give you access to common selection actions, deselection in particular. That way you no longer need to switch to the selection tool to remove a selection when you don’t have a keyboard available.
When you’re transforming an image, transform actions are shown here instead, since you can’t really manipulate a selection during that.
The bar can be relocated to a different spot on the canvas or disabled altogether. It was suggested by CosmosX007 and Geese.
When the canvas is locked, the lock notices in the top-right corner will now provide buttons to let you get out of the lock if appropriate. For example, if you’re an operator and the canvas is locked, there’ll be a button to unlock it. Or when you’re using the gradient tool that requires a selection to operate in, it will give you buttons to select everything or the current layer bounds.
There will also be notices when you’re in layer or group view mode, with a button to get out of them. These are usually modes that you only stay in temporarily, so I think it makes sense to have a way to exit them again quickly readily available. If you don’t like this, you can also disable them via the menu on the notice itself.
Frame view mode will only prompt you to exit it if you select a layer that isn’t visible in the current frame, since this is a mode you stay in for a long time.
This was suggested by Geese and Phoneme.
When you fiddle with the animation timeline to a sufficient degree, Drawpile will now automatically switch to frame view mode for you. This basically saves having to press the button at the top of the timeline every time, since anything you’re doing on there really only makes sense in frame view mode.
The reason this didn’t happen before is that we didn’t want people to get stuck in frame view mode and not know how to get out of it. However, since it now shows the notices mentioned above when you select a layer outside of the animation, that shouldn’t leave anyone stuck for too long.
You can now use the stabilizer and smoothing on lasso selects, just like you can on lasso fills. Note that to get smooth edges, you also need to turn on anti-aliasing.
Drawpile will no longer hang when switching tools while smudging. This was reported by and found with the help of D’mitry on Discord.
You can now detach the chat in different ways: as a regular window, on top of Drawpile’s window or on top of everything. This is available on desktop operating systems only and may not work on all configurations of Linux window managers and such. This was suggested by Blozzom and Bluestrings on Discord.
Default layers are now properly restored when reconnecting and should actually do what they’re supposed to. This was reported by Bluestrings.
There’s now a new crop to selection action in the selection menu. This is really the same as the resize canvas action, it’s just here so that people who are looking for cropping specifically can find it.
The transform tool will no longer remember the sampling mode across restarts, since it’s too easy to mess up your art with it accidentally when you still have it set to Nearest or Binary and aren’t zoomed in enough to notice that it’s making everything look scraggly.
Setting the hue slider to 359 in the HSL color space no longer makes the color turn gray. This was reported by BornIncompetence on Discord.
]]>