AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2006.06.02 15:22 "[Tiff] TIFFWriteRawStrip with multi-strip?", by
2006.06.02 16:35 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.02 17:08 "RE: [Tiff] TIFFWriteRawStrip with multi-strip?", by
2006.06.07 08:50 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Gerben Vos
2006.06.07 11:48 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.07 13:48 "RE: [Tiff] TIFFWriteRawStrip with multi-strip?", by
2006.06.02 17:20 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Joris Van Damme

2006.06.07 13:48 "RE: [Tiff] TIFFWriteRawStrip with multi-strip?", by

> -----Original Message-----
> From: Gerben Vos [mailto:Gerben@ZyLAB.COM]

...not to mention that G4 produces a stream of bits, not bytes, so the boundary between two strips will not fall on a byte boundary in most cases, and it is even less likely that it will be regular enough to determine a rows-per-strip number.

Makes me wish Intel (or anyone) would introduce some "move-with-bit-offset" instructions for external memory access.

MOV   CL,  7                  ; offset by +7 bits

MOVBO EAX, [some_variable] ; fetch into EAX 32 bits from address of some_variable + CL number of bits

If bits "around" the target address were always fetched anyway (haven't thought about how to deal with bounds), there would be very little overhead for reads.

*shrug*