On 18/07/12 10:45, Aaron Paden wrote:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game.

You can try turning off color management in your preferences (there's a bug in GIMP 2.8 that makes painting tools and selection widgets slower when color management is active) and you can try with different tile memory settings but I'm afraid your system specs are low for high resolution painting in a program like GIMP.

hth,

Gez.

Hello Gimp dev !

I also have noticed the low efficience and I think it's very necessary to improve that. With a quick google search I've found a code profiler called gprof. It seems easy to use, it would require to compile gimp with an extra "-pg" and disable any compiler optimization.

I'm actually very novice yet and my knowledge on GIMP internals is pretty limited. So, those more expert developers: What do you think ? Would it be difficult to compile GIMP with gprof ? Would it be really useful for improving GIMP performance ?

Greetings Guiu Rocafort

On Wed, Jul 18, 2012 at 3:45 PM, Aaron Paden wrote:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game. ______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/**mailman/listinfo/gimp-**developer-list

-------- Original-Nachricht --------

Datum: Wed, 18 Jul 2012 17:06:07 +0200 Von: Guiu Rocafort
An: Aaron Paden
CC: gimp-developer-list@gnome.org
Betreff: Re: [Gimp-developer] gimp 2.8 prohibitively slow

Hello Gimp dev !

I also have noticed the low efficience and I think it's very necessary to improve that. With a quick google search I've found a code profiler called gprof. It seems easy to use, it would require to compile gimp with an extra
"-pg" and disable any compiler optimization.

I'm actually very novice yet and my knowledge on GIMP internals is pretty limited. So, those more expert developers: What do you think ? Would it be difficult to compile GIMP with gprof ? Would it be really useful for improving GIMP performance ?

Greetings Guiu Rocafort

On Wed, Jul 18, 2012 at 3:45 PM, Aaron Paden wrote:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying

to

open large images like MyPaint encourages, I'll have to run to another

tty

to try and kill the process so I can continue to use my computer. I've

got

an old Pentium 4 with only about half a gig of RAM. A bit behind the

times,

but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have

much

experience. I doubt I could write anything any faster. But maybe I can

do

something to help identify bottlenecks? Anything I can do to help, I'm

game.

______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org

https://mail.gnome.org/**mailman/listinfo/gimp-**developer-list

--
*Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html*

On Wed, 2012-07-18 at 10:27 -0500, Aaron Paden wrote:

Even krita is a little better, which I thought was surprising. It's able to at least load my largest image (8960x9088, 7 MB) after awhile without halting and crippling my DE,

Try increasing the tile size in your gimp preferences e.g. to two gigabytes (and make sure you have at least three gigabytes of swap space).

8960x9088 is more like a 300 megabyte image in memory, if it's in RGB mode - 4 bytes per pixel (R G B and Alpha), so 4 * 8960 * 9088
gives 325713920 bytes, and dividing that by (1024 * 1024) gives 310.625 megabytes.

A difference might be that MyPaint treats unpainted canvas areas specially. Krita was from the start designed for professional use with CMYK support, and hence targets images for print - your image isn't all _that_ large in the PhotoShop / commercial print world - and so may optimize large images more, I don't know.

To work with this image in gimp on a 32-bit system you will need:

(1) to have as large a tile cache size as you can -that's the amount of memory gimp devotes to keepng the image in memory instead of on disk

(2) have the Undo History window in your dock, and use the button at the bottom right to Discard Undo History roughly every 30 to 50 brush strokes. Unfortunately I don't think you can bind that to a keyboard shortcut, so you need the undo history window docked.

(3) save work frequently as xcf.gz - do not overwrite the same file each time, in case you run out of memory while gimp is saving the file. Save and Expert go much faster if you discard the undo history first.

(4) turn off thumbnails everywhere you can, e.g.,
in edit/preferences/interface,
turn off Enable Layer & Channel Perviews in edit/preferences/Toolbox,
. turn off the "show active image"
in edit/preferences/Image Windows, you may want to . turn off Show brush outline
this may make painting faster but unuseable, though. . set pointer mode to rendering to crosshair only . set pointer rendering to black and white

(5) make sure your gimp title bar shows the amount of memory in use - if it doesn't, go to Edit/Preferences under Image Windows, Title and Status; for Image Title format I have

%D*%f-%p.%i (%t, %L) %wx%h %m (the default except for adding %m for memory) and for Image status bar I have
%n (%m)
(the default)
That way if the status bar is saying something else, e.g. while you're painting, you can still track memory usage easily.

(6) in edit/preferences/colour management, . set Mode of operation to No color management (I just notice "colour" is misspelt there)

(7) do not use a theme with transparency. In Windows, use the classic windows theme. In Linux, do not use compiz or a compositing window manger (the ones that put drop shadows under windows), because these to tend to reduce (sometimes halve) painting speed and increase memory usage.

Hope this helps.

Liam

On 07/18/2012 04:55 PM, Guillermo Espertino (Gez) wrote:

On 18/07/12 10:45, Aaron Paden wrote:

>

You can try turning off color management in your preferences (there's a bug in GIMP 2.8 that makes painting tools and selection widgets slower when color management is active)

That actually works! Turning off Color management does increase performance. Can we expect this bug to be fixed in 2.8.x?

and you can try with different tile memory settings but I'm afraid your system specs are low for high resolution painting in a program like GIMP.

hth,

Gez.

There are a few performance improvements to color management already - those will be available when 2.8.2 is released.

Look here for more details: https://bugzilla.gnome.org/show_bug.cgi?id=645345

-- drawoc

On Wed, Jul 18, 2012 at 12:30 PM, Vladimir Savic wrote:

On 07/18/2012 04:55 PM, Guillermo Espertino (Gez) wrote:

On 18/07/12 10:45, Aaron Paden wrote:

You can try turning off color management in your preferences (there's a bug in GIMP 2.8 that makes painting tools and selection widgets slower when color management is active)

That actually works! Turning off Color management does increase performance. Can we expect this bug to be fixed in 2.8.x?

and you can try with different tile memory settings but I'm afraid your system specs are low for high resolution painting in a program like GIMP.

hth,

Gez.

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

One thing I noticed is that actually loading the images is very expensive, and gimp doesn't behave very well while it's happening. It took several minutes to load the large image, and while it was doing it, X was mostly unresponsive. Is there room for improvement here?

Same effect under WIndows 7 with GIMP 2.8 and GIMP 2.8.1 - Partha compilation but I think developers are already aware about that - probably is a normal fact in the
middle of transition new GEGL core. Side effects are expected. Beside the problem with large images in 2.8.x - also you will find some crashes related to memory allocation when you will use GEGL for rendering the canvas and colors or when you will use GEGL Operations.

If you use compilations from trunk - versions bigger than 2.8 (mean 2.8.1) - you will also
observe some GEGL operation get serious speed on execution, especially blur operations - on Windows 7 and GIMP 2.8.1 from partha.com, gaussian blur perform very fast now
even on mid-to-large images. The UI controls are not responsive but I use input fields and results are
rendered instantly.

2012/7/19 Aaron Paden :

Hello, Liam. I've tried your suggestions and have gotten some pretty good results. My large image used for this test is still not practically editable, but I was having problems even with relatively small images in gimp, and these workarounds have really improved gimps responsiveness and usefulness for me. The brush can now (mostly) keep up with my hand! :) Thanks for your insight.

One thing I noticed is that actually loading the images is very expensive, and gimp doesn't behave very well while it's happening. It took several minutes to load the large image, and while it was doing it, X was mostly unresponsive. Is there room for improvement here?

On 07/18/2012 11:01 AM, Liam R E Quin wrote:

Try increasing the tile size in your gimp preferences e.g. to two gigabytes (and make sure you have at least three gigabytes of swap space).

To work with this image in gimp on a 32-bit system you will need:

(1) to have as large a tile cache size as you can -that's the amount of memory gimp devotes to keepng the image in memory instead of on disk

(2) have the Undo History window in your dock, and use the button at the bottom right to Discard Undo History roughly every 30 to 50 brush strokes. Unfortunately I don't think you can bind that to a keyboard shortcut, so you need the undo history window docked.

(3) save work frequently as xcf.gz - do not overwrite the same file each time, in case you run out of memory while gimp is saving the file. Save and Expert go much faster if you discard the undo history first.

(4) turn off thumbnails everywhere you can, e.g.,
in edit/preferences/interface,
turn off Enable Layer & Channel Perviews in edit/preferences/Toolbox,
. turn off the "show active image"
in edit/preferences/Image Windows, you may want to . turn off Show brush outline
this may make painting faster but unuseable, though. . set pointer mode to rendering to crosshair only . set pointer rendering to black and white

(5) make sure your gimp title bar shows the amount of memory in use - if it doesn't, go to Edit/Preferences under Image Windows, Title and Status; for Image Title format I have

%D*%f-%p.%i (%t, %L) %wx%h %m (the default except for adding %m for memory) and for Image status bar I have
%n (%m)
(the default)
That way if the status bar is saying something else, e.g. while you're painting, you can still track memory usage easily.

(6) in edit/preferences/colour management, . set Mode of operation to No color management (I just notice "colour" is misspelt there)

(7) do not use a theme with transparency. In Windows, use the classic windows theme. In Linux, do not use compiz or a compositing window manger (the ones that put drop shadows under windows), because these to tend to reduce (sometimes halve) painting speed and increase memory usage.

Hope this helps.

Liam

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Aaron Paden gmail.com> writes:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game.

You know, when you have a system that's probably 12 years old, it's good form to start by saying that you have one instead of complaining that an application developed in 2012 is "prohibitively slow". For example, you could use the subject line "running Gimp on an old PC". Just saying.

Hello Michael, Aaron,

On Thu, 19 Jul 2012 06:34:29 +0000 (UTC) Michael Grosberg wrote:

Aaron Paden gmail.com> writes:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game.

You know, when you have a system that's probably 12 years old, it's good form to start by saying that you have one instead of complaining that an application developed in 2012 is "prohibitively slow". For example, you could use the subject line "running Gimp on an old PC". Just saying.

That's right, even though when attempting to process image/data files that are, say, "modern". The OP didn't mention precisely how big they are ("trying to open large images like MyPaint encourages"), but I presume they are way bigger than image sizes that were conventional in the times P4 + 512Go RAM were common.

How big are they, Aaron?

Regards,

wwp

Aaron,

The problem anyway is with the right GIMP version - not strict related to the computer power
I have 2 computers
first - 32bit architecture, Intel Quad core with 4 Gb RAM + 1Gb RAM ATI RADEON HD
second - 64bit architecture with 8 processing cores with 8 Gb RAM + 1Gb RAM Nvidia video card

on both of them GIMP 2.6 can load big images without problems on the first computer GIMP 2.8 can't load a file bigger than 750MB but I've made that big file with GIMP 2.6 (in pixels was 53.000 x 33.000) with an Intel Dual core.

So if you really want to use GIMP for big images use GIMP 2.6 and your problems are gone.

2012/7/19 Aaron Paden :

On 07/19/2012 02:28 AM, wwp wrote:

even though when attempting to process image/data files that are, say, "modern". The OP didn't mention precisely how big they are ("trying to open large images like MyPaint encourages"), but I presume they are way bigger than image sizes that were conventional in the times P4 + 512Go RAM were common.

How big are they, Aaron?

MyPaint encourages large images because of the infinite canvas. It adds up pretty quickly. The largest one I was using to test gimp was 8960x9088. Just some doodles. More me testing the limits of gimp on my computer than trying to do something useful in that case. Gimp was unusably slow no matter what size image I use, but Liam's suggestions have made things much more manageable.

https://mail.gnome.org/archives/gimp-developer-list/2012-July/msg00074.html

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am 19.07.2012 08:34, schrieb Michael Grosberg:

Aaron Paden gmail.com> writes:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game.

You know, when you have a system that's probably 12 years old, it's good form to start by saying that you have one instead of complaining that an application developed in 2012 is "prohibitively slow". For example, you could use the subject line "running Gimp on an old PC". Just saying.

There is also a huge difference even on newer systems. If i compare how applications handle things, then Gimp 2.8 is currently on the top spot of being the slowest, most memory intensive graphic program. 2.6 is way faster, but still slow compared to other applications like myPaint. Overall i see various performance issues. If Gimp would be written in Java or Python then i would not complain so much...

seems that many peoples here don't get the fact that GIMP right now is in a full transition to a new processing core for graphic operations

all developers know that GIMP 2.8 is slow now - compared with 2.6 ...this is the transition cost

let's not transform this discussion in a 'GIMP 2.8 burn in hell...'

the initial topic was around GIMP 2.8 in old hardware and the conclusion was pretty clear >> for old hardware use GIMP 2.6

if you have to report use cases for specific bugs - developers can use your information in a positive way ..but just repeating "GIMP 2.8 is way slow" is not the good way ..we already know that.

BTW - probably many of your GIMP speed problems are already patched in trunk - they just can't trow a new build for every change...

2012/7/19 Tobias Oelgarte :

Am 19.07.2012 08:34, schrieb Michael Grosberg:

Aaron Paden gmail.com> writes:

So I mostly use MyPaint, but I'd like to be able to do some things in gimp, too. But gimp is way too slow on this computer. Especially trying to open large images like MyPaint encourages, I'll have to run to another tty to try and kill the process so I can continue to use my computer. I've got an old Pentium 4 with only about half a gig of RAM. A bit behind the times, but especially on Linux it's generally fast enough to get the job done.

Is there anything I can do to help improve performance? I don't have much experience. I doubt I could write anything any faster. But maybe I can do something to help identify bottlenecks? Anything I can do to help, I'm game.

You know, when you have a system that's probably 12 years old, it's good form
to start by saying that you have one instead of complaining that an application
developed in 2012 is "prohibitively slow". For example, you could use the subject
line "running Gimp on an old PC". Just saying.

There is also a huge difference even on newer systems. If i compare how applications handle things, then Gimp 2.8 is currently on the top spot of being the slowest, most memory intensive graphic program. 2.6 is way faster, but still slow compared to other applications like myPaint. Overall i see various performance issues. If Gimp would be written in Java or Python then i would not complain so much...

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, Jul 19, 2012 at 4:34 PM, SorinN wrote:

seems that many peoples here don't get the fact that GIMP right now is in a full transition to a new processing core for graphic operations

all developers know that GIMP 2.8 is slow now - compared with 2.6 ...this is the transition cost

I'd like to know what developers know that :)

Slow rendering in 2.8 has nothing to do with GEGL.

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, 2012-07-19 at 00:35 -0500, Aaron Paden wrote:

Hello, Liam. I've tried your suggestions and have gotten some pretty good results.

good!

One thing I noticed is that actually loading the images is very expensive, and gimp doesn't behave very well while it's happening. It took several minutes to load the large image, and while it was doing it, X was mostly unresponsive. Is there room for improvement here?

Here are some more notes but it's hard to o further without knowing an awful lot more about your situation, e.g. whether you face North when you look at the computer.

What else are you running? run "top" in a terminal and press M to sort by memory, see if anything is using a lot.

Quit and restart gimp before and after editing large images.

But most likely X is slow because your hard drive is slow, e.g. it's an ATA one that makes lots of CPU interrupts and hogs the bus. Make sure it is configured to use DMA - hdparm -i, or -I, might tell you. Older Linux distributions disabled that by default.

You might be able to stop some programs you don't use - e.g. in Mageia or Mandriva Linux you can use the control centre to disable services, or in Fedora or RHEL or CentOS (as well as Mandriva and Mageia) you can use chconfig from the command-line, to stop services like mysqld or spamd, and I've noticed in the past that this helps.

Having said all that, you should be aware that (1) gimp is moving to a whole new internal engine with 12 cylinders instead of four, and will undoubtedly use more gas at times; I don't think that's what's going on with 2.8 though.

(2) mypaint's infinite canvas is a very different data structure inside the program than gimp uses. Mypaint only instantiates the parts of the canvas where you draw, whereas gimp instantiates the whole canvas.

(3) probably the best thing you can do to improve performance on an older PC, apart from getting a new one :-), is to add memory. Make sure, if you can, that it's fully expanded.

(4) use a light-weight desktop environment, lxde or something, not kde or even gnome. Or just a window manager and no desktop, if you can work like that. Similarly, use a plain background pattern or solid colour on the desktop, not an image, and save maybe a megabyte of video memory.

(5) Most important of all, don't wear shoes :-)

Liam

Slow rendering in 2.8 has nothing to do with GEGL.

...but with what ? not because of refactoring towards full GEGL integration ?

I was thinking that this side effect is a normal stage for a software in transition and I was trying to temperate a bit the "GIMP 2.8 is slow" trend. But trying to do good seems to be wrong. Anyway, nothing is perfect, at least for you Alexandre - so let's (unnecessary) complicate the topic, if not related to GEGL transition, in a logical consecution next question is - why is slow then ?.

I'd like to know what developers know that :)

Now this is the real point over the pretty letter I. Well, you are free to ask them all - who am I to stop you ? Probably not just developers but all peoples who changed 2.6 for 2.8, but go on, ask developers just to be sure.

2012/7/19 Alexandre Prokoudine :

On Thu, Jul 19, 2012 at 4:34 PM, SorinN wrote:

seems that many peoples here don't get the fact that GIMP right now is in a full transition to a new processing core for graphic operations

all developers know that GIMP 2.8 is slow now - compared with 2.6 ...this is the transition cost

I'd like to know what developers know that :)

Slow rendering in 2.8 has nothing to do with GEGL.

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, Jul 20, 2012 at 1:04 AM, SorinN wrote:

Anyway, nothing is perfect, at least for you Alexandre - so let's (unnecessary) complicate the topic, if not related to GEGL transition, in a logical consecution next question is - why is slow then ?.

I'd like to know what developers know that :)

Now this is the real point over the pretty letter I. Well, you are free to ask them all - who am I to stop you ? Probably not just developers but all peoples who changed 2.6 for 2.8, but go on, ask developers just to be sure.

Let's try again:

I'd like to know what developers know that :)

Meaning: "No developers know that, because your assumption about the transition effect is incorrect" :)

The bug is known, the fix isn't trivial, mitch didn't have the time to do it for 2.8.

If anyone's willing to have a go at it, please join IRC to discuss it.

Alexandre Prokoudine http://libregraphicsworld.org

On 20 July 2012 03:25, Alexandre Prokoudine wrote:

On Fri, Jul 20, 2012 at 1:04 AM, SorinN wrote:

Anyway, nothing is perfect, at least for you Alexandre - so let's (unnecessary) complicate the topic, if not related to GEGL transition, in a logical consecution next question is - why is slow then ?.

I'd like to know what developers know that :)

Now this is the real point over the pretty letter I. Well, you are free to ask them all - who am I to stop you ? Probably not just developers but all peoples who changed 2.6 for 2.8, but go on, ask developers just to be sure.

Let's try again:

I'd like to know what developers know that :)

Meaning: "No developers know that, because your assumption about the transition effect is incorrect" :)

The bug is known, the fix isn't trivial, mitch didn't have the time to do it for 2.8.

Link to the bugreport please?

If anyone's willing to have a go at it, please join IRC to discuss it.

Alexandre - on this list many simply peoples (I mean not programmers or tech addicted guys) just come to ask questions or talk about problems they got using GIMP - they need simply answers. Generally they just observe and ask, they don't bring accusations. Simply put - for John Doe - GIMP 2.8 (not 2.8.x) is slower than GIMP 2.6 or 2.7. This what any average GIMP user can observe withe a free look.

They simply don't use 2.8.x from Partha, they don't compile, they don't follow the development progress - they just need a plain simple answer to a simple question. I didn't say that GIMP is slow because of GEGL (or GEGL is slow) I just explain that GIMP is in a transition to a new graphic core and developers need bug reports if possible not just words like " ..GIMP 2.8 is slow".Without a bug report or a test case such affirmations are useless. That's all. You also use this kind of tone in GIMP development related articles in libregraphicsworld, and this is why I don't understand sometime your appetite for polemic. I will never argue about "...GEGL is slow" - in fact in 2.8.1 GEGL operations (such Gaussian Blur perform really fast [ ..using input boxes not UI sliders ]).

Meaning: "No developers know that, because your assumption about the transition effect is incorrect" :)

;) I will not comment this paragraph because using formal logic it's easy (and persuasive also) to build an argumentation - but no-one need that. We have better things to do. Let's end this out-of-topic craziness here.

2012/7/20 Alexandre Prokoudine :

On Fri, Jul 20, 2012 at 1:04 AM, SorinN wrote:

Anyway, nothing is perfect, at least for you Alexandre - so let's (unnecessary) complicate the topic, if not related to GEGL transition, in a logical consecution next question is - why is slow then ?.

I'd like to know what developers know that :)

Now this is the real point over the pretty letter I. Well, you are free to ask them all - who am I to stop you ? Probably not just developers but all peoples who changed 2.6 for 2.8, but go on, ask developers just to be sure.

Let's try again:

I'd like to know what developers know that :)

Meaning: "No developers know that, because your assumption about the transition effect is incorrect" :)

The bug is known, the fix isn't trivial, mitch didn't have the time to do it for 2.8.

If anyone's willing to have a go at it, please join IRC to discuss it.

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, Jul 20, 2012 at 12:48 PM, Jon Nordby wrote:

The bug is known, the fix isn't trivial, mitch didn't have the time to do it for 2.8.

Link to the bugreport please?

https://bugzilla.gnome.org/show_bug.cgi?id=645345

As far as I can tell, a partial fix is in place thanks to Massimo.

On Fri, Jul 20, 2012 at 2:08 PM, SorinN wrote:

and this is why I don't understand sometime your appetite for polemic.

There is none, but I can't stop you from imagining things, can I?

Alexandre Prokoudine http://libregraphicsworld.org

Von: SorinN

Alexandre - on this list many simply peoples (I mean not programmers or tech addicted guys) just come to ask questions or talk about problems they got using GIMP - they need simply answers.

They need answers that are correct and verifiable.

Simply put, Alexandre has suggested that you should provide proof for your claims. He arguably wrapped this in a weird writing style.

I don't want to do the same, so I'll just be blunt:

Both parties, please back up your statements about the slowness due to the GEGL transition or due to a known bug. And skip the prose, strip it down to the mere facts.

The readers of this mailing list will thank you.

Regards, Michael