> 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. 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. Finally, the way to make the UI faster would be to do the resize in tiles. Udi ------------------------------------------------------------------------------ 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
