Jekyll2026-03-18T00:05:38+00:00https://docs.drawpile.net/feed.xmlDrawpileCollaborative DrawingDev Update: Week 10 and 11 of 20262026-03-16T22:00:00+00:002026-03-16T22:00:00+00:00https://docs.drawpile.net/devblog/2026/03/16/dev-updateThe last two weeks have had a good number of animation and other improvements. You can try out this stuff in the alpha release.

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.

]]>
Dev Update: Week 8 and 9 of 20262026-03-01T22:00:00+00:002026-03-01T22:00:00+00:00https://docs.drawpile.net/devblog/2026/03/01/dev-updateThe last two weeks have had several improvements with brush previews, some smaller features and several bugfixes. You can try it out in the alpha release.

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.

Different configurations of the brush preview

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.

Different configurations of the brushes dock with different previews

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.

Curve with X and Y input fields

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.

]]>
Dev Update: Week 6 and 7 of 20262026-02-15T22:00:00+00:002026-02-15T22:00:00+00:00https://docs.drawpile.net/devblog/2026/02/15/dev-updateThe last two weeks have been some work to support animations in timelapses, some other minor animation improvements, better scaling on Android and a rotation tool. You can test them in the alpha release.

Animation Timelapses

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.

Animation Playback Improvements

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.

Android Scaling

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.

Android scaling dialog with different interface sizes

Rotation Tool

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.

]]>
Dev Update: Week 4 and 5 of 20262026-02-02T22:00:00+00:002026-02-02T22:00:00+00:00https://docs.drawpile.net/devblog/2026/02/02/dev-updateThe last two weeks have mostly been more work on the project file format, adding support for project statistics and creating timelapses from them. You can try it out in the alpha release.

Project Features

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.

Statistics

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.

Project statistics dialog

Timelapses

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.

Timelapse dialog

Canvas Shortcut Actions

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.

Canvas shortcut edit dialog with action assigned

Minor Additions and Bugfixes

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.

]]>
Dev Update: Week 2 and 3 of 20262026-01-18T22:00:00+00:002026-01-18T22:00:00+00:00https://docs.drawpile.net/devblog/2026/01/18/dev-updateThe last two weeks have mostly been more work on autosaving and the project file format. The stuff described here is available for testing in the alpha release.

Project Files

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.

Minor Additions and Bugfixes

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.

]]>
Dev Update: Week 52 of 2025 and 1 of 20262026-01-04T22:00:00+00:002026-01-04T22:00:00+00:00https://docs.drawpile.net/devblog/2026/01/04/dev-updateThe last two weeks have been spent for the most part on getting autosaving to a usable state. It is integrated into the alpha release now.

Autosaving

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.

Autosave settings

Minor Additions and Bugfixes

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.

]]>
Dev Update: Week 50 and 51 of 20252025-12-21T22:00:00+00:002025-12-21T22:00:00+00:00https://docs.drawpile.net/devblog/2025/12/21/dev-updateThe last two weeks have mostly been spent on swapping out the settings integration and getting autosaving running.

Settings Swappage

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.

Autosaving

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.

Recovery dialog

]]>
Dev Update: Week 48 and 49 of 20252025-12-09T22:00:00+00:002025-12-09T22:00:00+00:00https://docs.drawpile.net/devblog/2025/12/09/dev-updateAfter releasing Drawpile 2.3.0, the last two weeks have been mostly “infrastructure” work for upcoming changes, so nothing too exciting to show yet.

Project File Format

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.

Settings Supplantment

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.

Minor Additions and Bugfixes

  • When using the hardware renderer, the canvas view’s dimensions are now forced to be even by adding a single pixel of padding if necessary. This is necessary on some devices to prevent the view getting scrunched in a weird way.
  • MyPaint brushes now handle stair-step curves properly. Previously they could end up generating values inside of a stair step, which didn’t make sense.
  • The user interface for MyPaint brush curves now doesn’t show the curve continuing straight before the first and after the last point, because that’s not accurate to what’s going on (what really happens is that the values go really high or low very quickly.)
  • You can now set a blank brush cursor in the tool preferences. This was suggested by mixnmatt on Discord.
  • Drawpile now tries harder to detect whether an eraser is brought near the canvas, even if the tablet doesn’t properly report it. This fixes the eraser not being detected on some Linux systems at minimum, possibly other operating systems as well. This was reported by Lauwenmark on Discord.
  • Rectangle selections now show the extents of the selection in the status bar. This was suggested by Mercia on Discord.
]]>
Dev Update: Week 45 to 47 of 20252025-11-16T22:00:00+00:002025-11-16T22:00:00+00:00https://docs.drawpile.net/devblog/2025/11/16/dev-updateThe last few weeks have mostly been focused on fixing bugs for Drawpile 2.3.0 and adding some new resources to it. Unless anything comes up, I’ll probably start building the final release of that version.

New Brushes

New brushes were added (all in the “Drawpile” category):

  • “Pencil 1”, a brush based on the 2B pencil from the Tanda category, but adjusted to use Wash mode instead. This was provided by Ben.
  • “Marker Line”, a line brush using the new Marker blend mode.
  • “Soft Shade”, a soft paint brush that works well for soft shading and lighting.
  • “Pixel 3”, a one-pixel brush with pixel-perfect enabled.
  • “Pixel Art”, a one-pixel brush with pixel-perfect and pixel art input enabled.
  • “Binary 1”, a binary line brush using the Marker blend mode. Based on a brush provided by Annoy.
  • “Binary 2”, a binary paint brush.
  • “Spray”, a pixel spraycan-esque brush. Based on a brush provided by lambda20xx.
  • “Edger 1”, a brush with a soft and a hard side. Provided by Blozzom.
  • “Wavy Ink”, a line brush based on Irregular Ink. Provided by Ben.

Examples of the new brushes

New Layouts

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

  • “Floofderg”, a layout for large screens with an extra view for the reference dock. Provided by Ausjamcian.
  • “Kerfluff”, a layout for right-handed use on tablets. Provided by Scruff.
  • “Lambda”, a layout for medium screens with extra views for the reference and color slider docks. Provided by lambda20xx.

Examples of the new layouts

Color Pickings

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.

Color sampling ring with thicker sides

Old Setting Transitions

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.

Minor Additions and Bugfixes

  • On Android, fiddling with sliders no longer shows text selection handles until you actually edit the text. This fix has also been contributed to Krita.
  • Long-presses for right clicks now behave better. They no longer get delayed by kinetic scrolling, calculate their activation distance correctly and act more like a real right-click would that causes less confusion for widgets its aimed at. These fixes have also been contributed to Krita.
  • A new setting to enable touch draw pressure was added. This is needed for certain screen tablets apparently. This was reported by SurgeonTaco on Discord.
  • Dragging a layer onto its own canvas no longer pastes it, since that was really only ever used accidentally. You can still drag layers onto other canvases though. This was reported by Blozzom and Pepper on Discord.
  • Server dprec templates no longer claim that they’re incompatible when they’re not.
  • The alpha lock feature is now a button next to the clip and inherit alpha buttons, rather than being under the lock menu. Previously, users not familiar with the latter would misinterpret the button and get completely stumped. This was reported by Phoneme.
  • On Android, opening the preferences dialog no longer exits full-screen in some cases.
  • If the screen is sufficiently large, you now get the desktop UI for the start and preferences dialog with the buttons on the side, rather than the small-screen versions where the buttons are all the way at the bottom. This was suggested by tiar.
  • UI text that contained characters not available on Android now replaces those characters with something that doesn’t show up as a box.
  • MyPaint brushes now enable smudge syncing by default, since several brushes require it. This matches with how MyPaint itself works.
  • On Android and the browser, saving/downloading a file now puts a proper filename into the name field and pre-selects the correct default extension from the list, rather than sometimes having garbage extra stuff in the name field and always selecting the top option.
  • When attempting to pick a color from the screen on Wayland, you now get an error message telling you to switch to X. This was reported by Phoneme.
  • In the browser, the pick from screen button is now gone entirely, since a web application can’t do that.
  • Reopening the main window in the browser no longer enters full-screen mode. This was reported by Bluestrings.
  • Reconnecting to a session in the browser using a drawpile.net account now automatically picks the same username again like it does on other platforms, rather than requiring an extra click there.
  • On fast reconnects, local state such as layer visibility, track visibility etc. are now preserved properly. This was reported by Bluestrings and hpar on Discord.
  • Using a text field on Android no longer makes hardware keyboard inputs stop working when using a keyboard like GBoard. This fix was also contributed to Krita. It reported by justanotatest on GitHub.
  • The chat now unfocuses when you collapse it so that you don’t keep typing into something you can’t see.
  • On Android, the application now falls back to internal storage when proper storage is unavailable. This was reported by Sherb.
  • Hardware and software renderers now use slightly different zoom levels from each other, optimized for the way they work. This improves image quality and reduces jitter.
  • The hardware renderer now uses single-buffering by default, rather than the system default that might introduce massive input delays.
  • Infinitesimally tiny, totally transparent or infinitely soft brush dabs are now properly ignored again. They incorrectly only got ignored when all three criteria were fulfilled, rather than any one of them. This was reported by Blozzom.
]]>
Dev Update: Week 42 and 43 of 20252025-10-26T22:00:00+00:002025-10-26T22:00:00+00:00https://docs.drawpile.net/devblog/2025/10/26/dev-updateIn the last two weeks, some new user interface features have been introduced and Drawpile 2.3.0-beta.4 has been released. Unless any major issues are found, this will get released soon, since the latest Android and macOS versions require it.

Hardware Renderer Performance Fix

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.

Selection Action Bar

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.

On-Canvas Noticing

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.

Automatic Frame Mode Switching

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.

Lasso Select Stabilizer

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.

Minor Additions and Bugfixes

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.

]]>