On Thu, Oct 18, 2012 at 3:47 PM, maderios wrote:

Hi
When saving png image (ex 4496 3000 pixels) Gimp is very slow. I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. Any solution about a multi-threaded Gimp ?

Not in the stable version, sorry.

Alexandre Prokoudine http://libregraphicsworld.org

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

On Thu, Oct 18, 2012 at 3:53 PM, maderios wrote:

Not in the stable version, sorry.

May be in the future ?

Sure :)

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine wrote:

On Thu, Oct 18, 2012 at 3:47 PM, maderios wrote:

Any solution about a multi-threaded Gimp ?

Not in the stable version, sorry.

What about the 'Number of processors' option in the Preferences/Environment dialog?

Kind regards,

Sven

On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote:

I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image.

If you're talking about saving a file, there's not much that can be done - saving isn't something that can be parallelized.

Am Thursday 18 October 2012 21:05:35 schrieb Jernej Simončič:

On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote:

I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image.

If you're talking about saving a file, there's not much that can be done - saving isn't something that can be parallelized.

Well... writing to disk sure can't, but I guess there are image compression algos that can utilize multicores? After all, formats as png and jpg as far as I know, correct me if I'm wrong, tile the image and work on the tiles first.
so if one would allocate a target memory area in RAM first and then fill the mem map with the to-be-saved data one could open a file handle right from the start and copy the mem portions to disk as they get filled by the compression algo.

Or another approach would be make a copy of the image in RAM and do the save in the background. That way when using the same file name one would even narrow the state transition of the file to a minumum.

Just an idea.

On Fri, 2012-10-19 at 16:50 +0200, Dexter Filmore wrote:

Am Thursday 18 October 2012 21:05:35 schrieb Jernej Simončič:

On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote:

I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image.

If you're talking about saving a file, there's not much that can be done - saving isn't something that can be parallelized.

Well... writing to disk sure can't, but I guess there are image compression algos that can utilize multicores? After all, formats as png and jpg as far as I know, correct me if I'm wrong, tile the image and work on the tiles first.

Yes, both jpeg and png are amenable to some thread support. For that matter, disk writes can be parallelized and this can in fact help with perceived performance, although it an also make the system so busy it appears to "freeze up" during a save. Since saving a PNG file takes several minutes even on fairly fast computers I can sympathize with the desire to make it go faster.

so if one would allocate a target memory area in RAM first and then fill the mem map with the to-be-saved data one could open a file handle right from the start and copy the mem portions to disk as they get filled by the compression algo.

The problem with this is that you don't know in advance how much memoro to allocate or where to write, because the compression varies depending on patterns of light and dark (for example) in the image.

Or another approach would be make a copy of the image in RAM and do the save in the background. That way when using the same file name one would even narrow the state transition of the file to a minumum.

It's done in a separate process right now, but copying the image in memory, if it's, say, a one gigabyte image, might be problematic. And the images that need to be sped up are the fast ones.

It might be faster in some cases for gimp to do a "merge visible layers" before a save, I don't know.

Liam

Hi,

On 10/19/2012 10:29 PM, Liam R E Quin wrote:

so if one would allocate a target memory area in RAM first and then fill the mem map with the to-be-saved data one could open a file handle right from the start and copy the mem portions to disk as they get filled by the compression algo.

The problem with this is that you don't know in advance how much memoro to allocate or where to write, because the compression varies depending on patterns of light and dark (for example) in the image.

I've never actually coded png compression so correct me if I'm wrong.

If you have n cores. You allocate n blocks of memory assuming worst compression outcome and start to parallely compress blocks you only use a reasonably small amount of memory. (n times the worst case size of a png tile). For each block that is ready and can be appended to the disk file, you write out the block ans start to compress the next unhandled block. Of course this is asynchronous as some blocks will finish to compress before the next-to-be-written-out is still working, but you still speed up compression by a big factor and still have a small and static compression buffer.

If you add a write-out-queue you can achieve a more effective parallelism while still limiting memory usage.

Just my 2c.

Bye Bgs

Or another approach would be make a copy of the image in RAM and do the save in the background. That way when using the same file name one would even narrow the state transition of the file to a minumum.

It's done in a separate process right now, but copying the image in memory, if it's, say, a one gigabyte image, might be problematic. And the images that need to be sped up are the fast ones.

It might be faster in some cases for gimp to do a "merge visible layers" before a save, I don't know.

Liam