Re: [Gimp-user] multi-threaded Gimp

2012-10-19 Thread maderios

On 10/18/2012 09:05 PM, Jernej Simončič wrote:

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.

It's not only saving. When you save a .png, you compress it. Saving with 
Gimp is slow because it compress .png . Saving .xcf is very quick 
because no compression, I think...

Greetings

--
Maderios

Art is meant to disturb. Science reassures.
L'art est fait pour troubler. La science rassure (Georges Braque)

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


Re: [Gimp-user] multi-threaded Gimp

2012-10-19 Thread Dexter Filmore
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.


-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d--(+)@ s-:+ a C UL++ P+++ L+++ E-- W++ N o? K-
w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ 
b++(+++) DI+++ D- G++ e* h++ r* y?
--END GEEK CODE BLOCK--
___
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list


Re: [Gimp-user] multi-threaded Gimp

2012-10-19 Thread Liam R E Quin
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

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

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


Re: [Gimp-user] multi-threaded Gimp

2012-10-19 Thread Bgs


 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



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


Re: [Gimp-user] multi-threaded Gimp

2012-10-18 Thread maderios

On 10/18/2012 07:10 PM, scl wrote:

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?


Preferences/Environment
processors to use 8

Regards
--
Maderios

Art is meant to disturb. Science reassures.
L'art est fait pour troubler. La science rassure (Georges Braque)

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


Re: [Gimp-user] multi-threaded Gimp

2012-10-18 Thread 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.

-- 
 Jernej Simončič  http://eternallybored.org/ 

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