RSS/Atom feed Twitter
Site is read-only, email is disabled

scale-region.c

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

scale-region.c Sven Neumann 23 Aug 23:53
  scale-region.c Geert Jordaens 24 Aug 14:59
   scale-region.c Sven Neumann 24 Aug 19:09
    scale-region.c Liam R E Quin 24 Aug 21:27
     scale-region.c Sven Neumann 25 Aug 09:46
      scale-region.c Liam R E Quin 26 Aug 16:57
Sven Neumann
2008-08-23 23:53:56 UTC (over 16 years ago)

scale-region.c

Hi Geert,

I have a small patch to scale-region.c that I would to have your opinion on. I noticed that the current code sometimes does an unneeded copy operation. This happens when the scale factor is 2^n. For example when an image of 800x600 pixels is scaled to 400x300. The function determine_scale() then decides that a first scale step to 400x300 needs to be made and the result is then scaled again with a scale factor of 1.0. There's even an optimization n the scale() function for this special case.

Attached is a patch that changes determine_scale() to avoid this extra step. Is there anything that I am missing or do you agree that it should be safe to apply this?

Sven

Geert Jordaens
2008-08-24 14:59:51 UTC (over 16 years ago)

scale-region.c

Sven Neumann wrote:

Hi Geert,

I have a small patch to scale-region.c that I would to have your opinion on. I noticed that the current code sometimes does an unneeded copy operation. This happens when the scale factor is 2^n. For example when an image of 800x600 pixels is scaled to 400x300. The function determine_scale() then decides that a first scale step to 400x300 needs to be made and the result is then scaled again with a scale factor of 1.0. There's even an optimization n the scale() function for this special case.

Attached is a patch that changes determine_scale() to avoid this extra step. Is there anything that I am missing or do you agree that it should be safe to apply this?

Sven

------------------------------------------------------------------------

Sven Neumann
2008-08-24 19:09:13 UTC (over 16 years ago)

scale-region.c

Hi,

On Sun, 2008-08-24 at 14:59 +0200, Geert Jordaens wrote:

I see no problem with that,it should be safe.

Thanks for the review. I have committed this change and some other cleanups and optimizations to SVN trunk last night. This gives a small but noticeable speedup. I hope that my changes did not introduce any new bugs, but I am quite confident that I haven't broken anything.

Sven

Liam R E Quin
2008-08-24 21:27:53 UTC (over 16 years ago)

scale-region.c

On Sun, 2008-08-24 at 19:09 +0200, Sven Neumann wrote: [...]

Thanks for the review. I have committed this change and some other cleanups and optimizations to SVN trunk last night. This gives a small but noticeable speedup. I hope that my changes did not introduce any new bugs, but I am quite confident that I haven't broken anything.

Some informal (approximate) timings with a grayscale image, 13818x8480 pixels (a sketch by Sydney Jones).

before patch:

scale 50% = 18 seconds to freeze-at-end, 31 secs overall 17 seconds to freeze-at-end, 29 secs overall 51% = 14 seconds to freeze-at-end, 43 secs overall 11 seconds to freeze-at-end, 40 secs overall after patch:

scale 50% = 07 seconds to freeze-at-end, 24 secs overall 07 seconds to freeze-at-end, 25 secs overall 51% = 09 seconds to freeze-at-end, 34 secs overall 10 seconds to freeze-at-end, 35 secs overall

I did the timings more than once. I have 8G of RAM and a 7G tile cache size (on Sven's suggestion - it does seem to speed things up)

By "freeze-at-end" I mean that the progress bar stops moving when it is almost at the very end; my guess is that it's pushing onto the undo stack and also maybe generating a thumbnail for the undo history, but that's an uninformed guess :-)

The speedup for the first part is very noticeable, e.g. 18 secs -> 7 secs, but it makes the "frozen" part more noticeable, and as a result actually seems slower.

I did not do regression testing, comparing the results, sorry.

Liam

Sven Neumann
2008-08-25 09:46:09 UTC (over 16 years ago)

scale-region.c

Hi,

On Sun, 2008-08-24 at 15:27 -0400, Liam R E Quin wrote:

By "freeze-at-end" I mean that the progress bar stops moving when it is almost at the very end; my guess is that it's pushing onto the undo stack and also maybe generating a thumbnail for the undo history, but that's an uninformed guess :-)

This is just a bug in the progress code in scale-region.c. I am on it, should be fixed by tonight.

Sven

Liam R E Quin
2008-08-26 16:57:05 UTC (over 16 years ago)

scale-region.c

On Mon, 2008-08-25 at 09:46 +0200, Sven Neumann wrote: [...]

This is just a bug in the progress code in scale-region.c. I am on it, should be fixed by tonight.

Oh you sexy bean! Now that you ahve indeed stopped gimp from hanging... timings for the 13818x8480 image are

scaling down to 50%: 6 seconds (was 30 seconds a few days ago) scaling down to 51%: 6 seconds (was 41 seconds a few days ago)

Liam