On Jun 30, 2010, at 13:17:45, marti.ma...@littlecms.com wrote: > http://littlecms2.blogspot.com/2010/06/i-got-this-question-twice-so-here-are.html
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). Now we'll have to keep more transforms around based on the input/output formats, and we'll have to crowbar the code to create them in a totally different place, one that knows about the input/output format. You can see why I'm not pleased about this change. You can't just stick the cmsChangeBuffersFormat back in for those of us who prefer leaving our code the way it was while going through the lcms to lcms2 upgrade? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd smi...@multiad.com www.multiad.com ------------------------------------------------------------------------------ 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
