Feel free to code up a patch and submit it to us. We'll review it and
integrate it if it does whats its suppose to do.
galvanash wrote:
If adopted; I imagine this would be added as an additional> option/parameter to the
current ImageResize() function, like> 'isMultiPass'. A global code change would taunt
the dependency gods, no?> Some people may rely on the classic behavior for quirks
(those who want> processor speed and not quality, for example).
Well it is slower when done from CF, but if it was implemented
internally the speed difference would be much smaller... My thought
was if you wanted the normal behavior you would just use bicubic
(since it is the default anyway and is just as fast as bilinear) - I
kind of liked the idea that it wouldn't require any changes to the
calling interface...
What if it were added as another quality option? Instead of just
bicubic, bilinear, and nearest you added say "multistep binear" or
whatever it should be called. Then use the same logic as I originally
outlined (you don't want to do this if the new size is bigger than 50%
of the original size - it does more harm than good and it gets a lot
slower to boot).
--
online documentation: http://openbd.org/manual/
google+ hints/tips: https://plus.google.com/115990347459711259462
http://groups.google.com/group/openbd?hl=en
