On Tue, Oct 06, 2009 at 09:29:30PM -0500, Udi Fuchs wrote: > > I wonder how difficult it might be for the code to change such that it > > only processes the part of the canvas that is not clipped. ?Ideally, if > > it could do this for everything all the time, it would be pretty speedy > > in almost all cases. > > Most of the rendering code already works this way. If you run UFRaw on > a slow computer you can actually see that it renders the image in > tiles. The Bayer interpolation cannot be rendered in tiles at the > moment and this is needed for the 100% zoom.
Aha! I noticed the tiles...they seem based on the size of the image, not the size of the window, so it was hard to see at 100%. I suspect there is a significant amount of wasting processing off-screen because of the tile size. Also, I see the tiles are rendered in a raster format which is aborted if a slider is changed, then they update starting again from the top. Perhaps it would appear more responsive to start again where it left off instead, continuing around in a ring. This would avoid cases where only the top few tiles update during a continuous drag. I'll take a look. > Patches are welcome. Yes, I will take a look. :) I was profiling the dcraw portions a while ago with the intent to optimize it, but it seemed to be difficult to get anywhere. Cheers, Simon- ------------------------------------------------------------------------------ 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
