Good.
> Xscanimage now scans a 600 dpi image (8.5 x 14 inch) in about 3 minutes.
> I think this is a very good performance...
Bad. That's what I suspected: it looks like the reading of the
scanner data is timing sensitive. It looks like writing the data
through the pipe (which happens in chunks of 4KB/context switch) may
be the culprit. If so, may be we should first write the data to a
temp file when doing 3-pass scanning (AFAIK, there is no time
dependence for the 1-pass scanners, so the temp-files won't be needed
there). But maybe we can find a better solution.
> But one drop of bitterness again: no data.
> I think this shouldn`t be a big problem :-).
Well, that was the point of the patch. I'm trying to figure out
what's going on. IF you want a working backend again, just turn the
#if 1 into an #if 0.
Anyhow, can you do me a favor and run the same test again except two
small changes? The changes I'd like you to make is in function
reader_process() (in backend/mustek.c). There, replace the:
#else
with an
#endif
and then remove the #endif further down in the function. With this
change, data should be acquired again but it will also be slow again.
(I'm travelling right now so I can't send you a patch easily, but I
hope the above will do the trick).
What I'm interested in is the timing result that the reader_process
will spit out (btw, it's enough to send me the output with
SANE_DEBUG_MUSTEK=128---the output of dll etc isn't very interesting
at this point).
--david
-- Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/ To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com