Hi all -- While GIMP 2.9 is thriving with lots of possibilities, one thing remain as fact: it is dead slow. I most likely missed some of the efforts being done to try to compensate for that - like avoiding unnecessary pixel format conversions in some operations - and the possibility of having GEGL to run with open-CL acceleration. I think it is not an exaggeration to add that even with this, the current rendering model is dead slow. To the point of being unfeasible to work on a 1024x768 image in modern hardware - one simply can't paint. So we have to think one way out of it - GIMP 2.9 as it is, even if it get faster by a factor of 2 or 3, is not usable in real world scenarios - with pictures coming in the 13MP range, and the paintbursh lagging behind the cursor with a 20px radius brush One thing I think might be possible is to seriously thinka bout lazy rendering: all paint options get serialized as GEGL ops, and GIMP maintaisn 2 distinct graphs - 1 made for real time display, rendering a scaled down, cropped version of all operations - possibly even clipped to 8bpp with dumb acelerated 8bpp GEGL operators and no conversion needed (me hears Pippin scream even as I write) And the true image gets rendered in a background thread, with all the quality and format conversions needed - but no need to get real time with that. Maybe something along this was only being considered for the "post gtk 3, out of order GIMP of the future" - but given the application state, I think this is the only thing that could bring it back to usable speeds. So, we might as well start fleshing out what would be needed to get lazy rendering done, just to get it clearer for everyone, and maybe have one or more of the steps needed for that as Summer of Code projects. Regards, js -><- _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
