> but I'm afraid it's impossible to do without performance regression due to seek before every read.

I agree that this is key question.

I would hope that the performance hit wouldn't be so bad, unless there are actually two decompressions running concurrently.
So we can have an implementation that is generally correct, though some use scenarios result in slow execution.

OTOH, if the seek() call were a problem even if the new position is the same as the old one, they can be optimized out by a simple wrapper around fp.