Re: [Gimp-developer] 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 -- 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 www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer I see no problem with that,it should be safe. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 -- 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 www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
