> From: Thomas E Deweese [mailto:[EMAIL PROTECTED]] > >>>>> "EP" == Evenblij, Paul <[EMAIL PROTECTED]> writes: > > EP> Question: can anyone tell me what's the rationale for the decision > EP> to implement a CRC class in PNGImageEncoder.java, instead of using > EP> the JDK class java.util.zip.CRC32 ? > > I don't know if there are deeper technical reasons but the primary > one is that the PNG encoder was donated from Java Advanced Imaging and > it did it that way, and since the code works we haven't really gotten > around to poking at it too much.
Sensible :) > I take it there is a good reason for asking the question, such as > it's sucking lots of time? If so feel free to submit a bug report > (including any benchmarking info would be great if you can) and we > will add it to our list of things to do, or as always patches are > appreciated. I don't know about performance. I thought maybe *better* performance might have been the reason. I need CRC checking for raster image caching, and originally wanted to propose moving the CRC class to the utils package. But if I can use CRC32 or Adler32 from the JDK without performance deterioration, I will do so. (And also submit a patch to remove it from the PNG encoder) Cheers, Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
