Brainstorming/Performance

From MyPaint

What areas of MyPaint performance has room for improvement? And how can we improve it?

This is a brainstorming page, a place for new ideas and suggestions. To contribute, please follow the these guidelines and help us keeping the wiki organized.

[edit] Drawing performance

Whats the biggest limit to performance here? Rendering? Updating surfaces?

[edit] Speed and Interaction Improvements

In the features section it was mentioned that for interactive rotation the algorithm you use can't keep up, any reason not to use a proxy image for the rotation which is roated in realtime, and then rotate the real image after application? For speed improvement on large images - have two versions of the image, a temp/low resolution, and the high resolution - update the low resolution immediately during the drawing giving visual feedback, and the in the background update tiles of the high res image, and copy the high res image update to canvas as they finish getting calculated. (Tom Musgrove)

Also have you looked at openimageio and/or GEGL - both support tiling of images. (Tom Musgrove)

I didn't know openimageio, but GEGL of courses, yes. And MyPaint also does tiling. Fast rotation would be nice to have, and sure is possible to get with some work; but I think there are many other things to do that are more important. --maxy 19:29, 26 April 2010 (UTC)

[edit] Startup time

We currently (Jan 2010) rely on almost every part of the application to be initialized before the user is a allowed to start using it. If we can initialize non-primary windows (settings, layers, brush*) on demand instead of on startup, that would probably help a bit. Similarly if we only instantiate one brush object (current/default brush) instead of one for each and every brush.

I think brush loading is a problem because of the amount of brushes that are loaded. One thing to do is also to reduce the number of "core" brushes (supplied in the repository) and make a way of installing brushes and brush-packs from GUI. I know that this is not the solution but I just thought I may write it here as well. Also a splash screen would be nice to keep the users entertained ;) --Lukacu 12:38, 8 January 2010 (UTC)

I did some testing. On my system startup time increases almost linearly (O(n)) with number of brushes. This because most of the time (~70%) is spent initializing the brushmanager which loads each and every brush sequentially. For each brush, time is spent primarily on two things: 1) Instantiating the brush and loading dynamics/settings 2) Creating a pixbuf of the preview. Source data

So what I want to do is 1) Instantiate and load brushes when needed (when user activates it). Optionally also 2) Create the pixbufs when needed (when brushgroup is shown) --Jonnor 14:29, 30 January 2010 (UTC)

[edit] OpenRaster save performance

Often the user will done have minor incremental changes between two saves. So only saving what has changed would probably be a huge improvement for typical use-cases. This could be implemented on several "levels", but one simple action would be to only save the layers that have been modified.

I think that libora is the way to go here. Making it all native code and without temporary saving of layers to the disk. Then investigate the possibility of having zero (or some kind of minimal) compression for layers because it does not add much to the overall size reduction. --Lukacu 12:31, 8 January 2010 (UTC)

PNG compression is split in two parts; pre-processing (filtering) and gzip compression. For the latter most PNG implementation use zlib, which has the option to use zero compression (ref). So that should be possible. --Jonnor 14:00, 9 January 2010 (UTC)

Converting from our internal data structure to gdk pixbuf also takes a considerable amount of time. Anything we can do about that? I suspect not...

I guess the problem is, that all the tiles have to be combined into a single array. I see no solution for ORA format here but we may consider using some kind of internal format for scraps that would be able to save just tiles ... just a thought/idea --Lukacu 15:24, 9 January 2010 (UTC)

One user pointed out that in some cases the saving of the strokemap took the most time. Should we have an option to disable this? Can we make it faster?

First step is to make an ORA to reproduce this. Second step is to profile it and see where it spends most of the time. Only after that we may discuss about how to make it faster. maxy 14:48, 10 January 2010 (UTC)

[edit] Memory usage

Memory usage is seemingly quite high. Is there anything we can do to make it be lower?

On IRC using compression for the tiles came up. While this is a possibility it will introduce higher CPU usage and is quite complex. So we should pick lower hanging fruit (if any) before considering that.

Are we talking about memory usage after startup, or the difference from startup memory usage to a big ORA image, or what? maxy 14:44, 10 January 2010 (UTC)