Steve, thanks much for the feedback! Yes, this circular buffer stuff is confusing to me as well. I still don't grasp it totally...
> Lawrence was a bit confused about the purpose of this code, too. Here is a copy of an off list explanation I sent
> him..........
> There is a limitation in the work I did, that if you try to scan a Y > line
> image you will actually get Y - b lines of scan, where b is the > number of
> lines absorbed by the circular buffering process. It shouldn't >
> Anyway, that's not your problem here, as the scan you are attempting > is large.
Is there a chance you could expand on the circular buffer and how its used for me. How do you mean "absorbed"? Does it totally go away or is there some sort of drain()'ing going on at the end that flushing out the buffer?
> The above code should be OK, if my assumption is right. If
> TxSource_remaining() is less than one scan line less than the size > of the
> circular buffer there will be major trouble!
> The question you need to answer is how does:
> [snapscan] inquiry: expected total scan data: 25158951 bytes
> lead to:
> [snapscan] TxSource_remaining =30592
Here is what was going on when I run in to the problem. I am
performing a 600 dpi scan of a predef-window = 6x4. Results in the
following initial values:
[snapscan] inquiry: pixels per scan line = 3599
[snapscan] inquiry: bytes per scan line = 10797
[snapscan] inquiry: number of scan lines = 2407
[snapscan] inquiry: effective buffer size = 21594 bytes, 8 lines
[snapscan] inquiry: expected total scan data: 25988379 bytes
[snapscan] measure_transfer_rate: have ring buffer
Now, notice that I'm right at calling mesaure_transfer_rate() to do
the fake scan of a few lines (rounded to a 128 byte boundry). There
is an initial call to scsi_read() so that we get 1 read from the
scanner. Then it does a create_source_chain() which among other
things forces cb_start = -1.
This is an immediate case were the circular buffer hasn't read
anything but we have data to process and its going to be less
then the circular buffer's total size. I'm getting values similar
to TxSource_remaining() = 21594 cb_size = 91000 and cb_line_size = 10797. Do the math and you get a very negative number coming
out of RGBRouter_remaining() since cb_start = -1.
The reason the buffer sizes don't match is something to do with
RGBRouter_init() is multiplying the buffer size by some factor
related to each R, G, B value it needs to read but the
measure_transfer_rate() function is not taking the same thing
into account.
Any pointers? Currently, I'm thinking its better to simply have
it return the value from TxSource_remaining() when cb_start == -1.
This cures my problem but perhaps it trashs data at the end of the
scan where there was already a good chance it was going to be
trashed anyways??? Thoughts?
Thanks much,
Chris
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sun Nov 19 2000 - 19:07:12 PST