On Mon, Mar 4, 2013 at 9:24 PM, Joao S. O. Bueno wrote:

While GIMP 2.9 is thriving with lots of possibilities, one thing remain as fact: it is dead slow.

O'RLY?

I will defer to mitch whether it is wise to do this type of GIMP-wide re-architecting as summer of code.. personally I doubt it to be a good thing to do in particualar changing what one wants to do and adding even more moving parts during a time of transition; instead of focusing on profiling and optimizing what one can. We have seen much better performance earlier in the 2.9 cycle (where things already were making significant use of GEGL) thus there likely is some rather low hanging fruit that could mean an order of magnitude better performance.

Making GEGL able to lazily render previews to scaled down mipmap levels is something that could improve display performance/layer compositing in current GIMP but not painting nor application of filters. It would still bring some benefit, it doesn't touch parts which are already in significant flux and it will provide bigger benefits in the future. Public APIs in GEGL that will be touched by such changes (most of them at least) have already gotten additional arguments in preparation for such changes in hope that we do not have to break API for operations. Working on 50% 25% or 12.5% of the pixels should already provide a significant boost in performance and doing 8bpc would not be giving comparable benefit to that.

/

El 04/03/13 11:24, Joao S. O. Bueno escribi:

[snip]

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.

+1000!

While I was reading the previous thread I was wondering how much performance can be achieved with optimizations, and how far is GIMP 2.9 from a reasonable speed according today's standards. As Joao said, even boosting the speed by 300% we're still far behind the performance one would expect from a tool like GIMP.

Maybe it's time to apply all the cheats available to make GIMP fast. Work with scaled down proxies when the view is at < 100%, constrain the feedback of filters to the visible region of the image, and do everything else in the background.
I know this issue has been brought to the table a couple of times in the last years. The answer was always that GEGL would provide the mechanisms to do that, but today, with GEGL, GIMP is effectively slower. Considering the current performance in GIMP 2.9, this should be a top priority task, because honestly, without a reasonable performance all the work done may seem useless to the eyes of the user.

Of course it's not useless and it is much appreciated :-)

Gez.

El 04/03/13 11:24, Joao S. O. Bueno escribi:

possibly even clipped to 8bpp with dumb acelerated 8bpp GEGL operators and no conversion needed

Here I don't agree. In my opinion 8bpc should be only available for file I/O. I wouldn't mind even if it's removed from the precision menu :D

Gez

On Mon, Mar 4, 2013 at 11:51 PM, Guillermo Espertino (Gez) wrote:

Considering the current performance in GIMP 2.9, this should be a top priority task

It already is. There are two major todo items for 2.10:

1. Better performance. 2. Porting plug-ins to GEGL.

Alexandre Prokoudine http://libregraphicsworld.org

On 4 March 2013 15:24, Joao S. O. Bueno wrote:

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.

Other raster application, including GIMP 2.8, are doing OK performance wise with a rendering mode that is very similar to GIMP uses now, so I don´t we necessarily need to do drastic changes there in order to fix the performance.

I think a useful GSoC project would be to define and implement some meaningful benchmarks for GIMP. If successful, that would give insights into what the causes of the current performance problems are. I believe that is needed for coming up with a good solution for current, and future performance issues.

Jon Nordby - www.jonnor.com