Re: Starting a discussion about SANE and TWAIN...

Andreas Beck (becka@rz.uni-duesseldorf.de)
Sun, 15 Aug 1999 02:40:20 +0200

> > If you are using SANE, you probably do so already. Most backends are
> > implemented to spawn off a reader process, which communicates with the
> > main (control) process via a pipe.

> Well, I'm not currently using SANE. I accept that if I am using a frontend
> like GIMP then I have no right to expect 300DPI color images to go wizzing
> by 2 per second.
> However, I want to be able to write SANE front-ends that can drive my
> back-end at those sorts of rates.

I was never talking about SANE frontends. I was talking about putting a
TWAIN frontend in front of a SANE frontend. For security reasons (as
explained in my other mail), I'd rather implement that using a split-process
model.

But I suppose for the application you have in mind, this is of no concern
anyway, as any bridging is to be avoided anyway, and it involves more effort
to make automated scans using TWAIN as compared to SANE anyway.

> I have put considerable effort into making sure the kernel mode device
> driver does *not* copy lots of image buffers around (app mmaps the image
> buffer which the card can access via DMA) and I don't want to see a SANE
> standard that does gratuitous copies.

SANE does not feature an interface that is _that_ direct. Sane images always
go through sane_read. That is to say:

You SANE backend would be able to mmap that buffer, but the frontend would
still have to sane_read it in to work with it. This does not involve a pipe,
but means an extra memory copy. (I do not think that giving access to backend
internal buffers is a good idea in general, as it will quickly require
quite some management overhead in the frontends to compensate for different
formats such internal buffers can have.)

Now it depends on what you actually want to do with the images:

If you want to process or store them in any way, I expect that extra copy
to be of no concern.

However if you will only be transferring them on a very high speed link
(>100Mbit), this might pose a problem.

memcpy should work at over 100MB/sec on the systems you target, so I suppose
it would be neglegible as long as the outgoing link is at less than 10MB/sec
or the processing takes more than about 50 CPU cycles per pixel.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com