Hi, On Wed, Oct 29, 2008 at 10:37 PM, Claus Berghammer (Bugzilla) <bugzilla2@xxxxxxxxxxxxxxxxxxxxx> wrote: > > Hello Gimp Developers, > > Sven Neumann asked me to move this thread from the Users mailinglist, to developers. The original discussion can be found here: > http://www.nabble.com/Scaling-in-Gimp-2.6-is-much-slower-than-in-Gimp-2.4-to20185528.html > > There is also a Bug in Bugzilla: > http://bugzilla.gnome.org/show_bug.cgi?id=557950 > > I extended my benchmarks and visual comparisons I've made so far, to give an more detailed view on whats the problem. > > Short said, it is all about: "Why is 2.6 so slow on scaling, compared to 2.4." ;-) > See yourself: > > > Benchmarking GIMP Scaledown Performance: > > Scale layer from 5000x5000px -> 2500x2500px: Is this a representative usage? I did a comprehensive benchmark (http://svenfoo.org/scaletest/) which showed the new code produced markedly better defined results, on pictures ranging from 277x185 to 1600x1200. That comprehensive benchmark was one of the main reasons this patch ended up in 2.6. In particular, you can see that the new algorithym preserves detail more accurately (see the Circular Zone plate, test image #6) > Conclusion: > Since the difference in processing time shows up even with interpolation "None", I think that the origin is not within the interpolation algorithms (or at least not only). Instead it seems to me (of course I'm just a user, not a developer), that there are some changes in the resize algorithm itself. If I understood the stuff in bug #464466 right, the scale routine is used several times in the interpolation routine. So, if the resize routine is slow, it accumulates in the interpolation routine. > > The speed penalty in 2.6 is more than just noticeable, and keeps some users away from 2.6. > > Also interesting is, the different alignment in 2.4 and 2.6. Why are layers that are processed with 2.4 always a bit "left and above" its 2.6 counterpart? 2.4 had some problematic behaviour on borders leading to the entire result often being wrongly offset. > It isn't really a problem, but if this isn't technical necessary, the behavior should be identical, to maintain "project compatibility" between different users/gimp versions. > As Sven Neumann already mentioned (see http://bugzilla.gnome.org/show_bug.cgi?id=557950), the upscaling could be made faster easily. > > But I think, that there is room for performance improvements in downscaling too... It is certainly possible. As Sven pointed out, we should probably first address the craziness of using interpolation routines (linear, cubic, lanczos) for downscaling. Do we even need to offer a choice of algorithym for downscaling (Box filter of appropriate size should be ok, except for None, which should be obvious.)? This is tricky because the user can downscale and upscale in one pass (eg. 150% scale on x axis, 80% on the y axis) _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
