Talk:Brainstorming/Performance

Speed and Interaction Improvements
- 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)

Startup time
- 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)

OpenRaster save performance
- 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)

Memory usage
- 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)