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 s
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 uninforme
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 quit
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 di
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 400x3
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_scal
