On Tue, Oct 06, 2009 at 07:40:25PM -0500, Udi Fuchs wrote: > > Changing zoom using the spin button will now recognize the magic > > percentages which can be replaced by a shrink factor. The shrink > > path is notivceable faster than the resize (as it should but I'm > > not entirely sure why). > > I took your patch a bit farther and got rid of conf->Shrink entirely.
It works well. > > resize is a bit slower than shrink because resize calculates the exact > ration of original pixels to target pixel weight. This is important if > original_size/final_size is close to 1. If original_size/final_size is > larger than about 2, we probably can have a quicker resize, but I'm > not sure it is worth while. Notice that dcraw_image_resize() avoids > floating point arithmetic, so it should be relatively fast. Not that it should matter much in this particular case but on modern hardware FP can be just as fast or even faster than int, depending on what you need to calculate. Nowadays there's a lot of silicon dedicated to FP on x86. On the other hand I would expect that integer arithmetic has more opportunities for future SIMD. What does matter anyway is careful coding (an occasional look at the generated asm is helpful), (data) cache footprint and openmp, I have some dcraw_api.cc work pending in that area which I'll post soon. -- Frank ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ ufraw-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ufraw-devel
