Hi, > The problem is, regardless of how this affects performance, we now > have to rip out and rewrite a large part of our code. It also means > that everything will work differently when the user is using lcms > than when they are using ColorSync. Previously, we could allocate a > number of transforms (or color worlds when using ColorSync) for > drawing to screen; one for drawing cmyk solid colors, one for drawing > a certain bitmap with a certain input profile, etc. Those transforms > (or worlds) could be kept around for long periods of time until the > user changed something, and it didn't matter what the format of the > input or output was, it just worked (it just worked in ColorSync, and > the cmsChangeBuffersFormat made it work in lcms).
I see. Maybe I could add this function to work on non-optimized tranforms. Please note that means an important throughput penalty, but maybe that is not so important. Ok, let me some days to figure out the required changes. Thanks for spotting the issue. Regards Marti. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
