1994.08.08 15:19 "Re: problems solved!?", by Sam Leffler

Hi again.

I think I solved the 64Kb array problem by simply splitting the (action<<8)|state array into two separate arrays -- one with the action (TIFFFax1DFSMaction) and another with the state (TIFFFax1DFSMstate). Whether this kills the announced performance increase for Fax compression in this release, I don`t know. Any comments? Sam?

You've effectively returned the code to the way it was in v3.3beta002. Aside from merging the tables (more cache locality and fewer arithmetic calculations to extract the encoded state info), the newer version has some reorganization of the encoded values that makes the decoder logic simpler and more easy for a compiler to optimize. I've also learned through my fax software that the decoder can be streamlined some more if I use setjmp/longjmp or similar to deal with error conditions and EOF (eliminates a number of checks in the heart of the decoding process). I hesitate to make these changes to the tiff library 'cuz of potential portability problems and because the overhead of setjmp is quite high when the G3 decoder is only doing a scanline at a time (in my fax software it makes good sense because entire pages are being decoded at once, so the setjmp is only done once per page of G3-encoded data).

As I said in a previous note I think the better longterm solution is to provide an alternate G3 decoder that is designed for memory-poor systems (or cases where folks don't want to pay the price for the full FSM-based decoder).

        Sam