kopia lustrzana https://gitlab.com/sane-project/website
90 wiersze
4.5 KiB
HTML
90 wiersze
4.5 KiB
HTML
|
<!-- received="Sat Aug 14 19:14:03 1999 PDT" -->
|
|||
|
|
<!-- sent="Sun, 15 Aug 1999 02:40:20 +0200" -->
|
|||
|
|
<!-- name="Andreas Beck" -->
|
|||
|
|
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
|||
|
|
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
|
|||
|
|
<!-- id="" -->
|
|||
|
|
<!-- inreplyto="199908142225.PAA01622@icarus.com" -->
|
|||
|
|
<title>sane-devel: Re: Starting a discussion about SANE and TWAIN...</title>
|
|||
|
|
<h1>Re: Starting a discussion about SANE and TWAIN...</h1>
|
|||
|
|
<b>Andreas Beck</b> (<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a>)<br>
|
|||
|
|
<i>Sun, 15 Aug 1999 02:40:20 +0200</i>
|
|||
|
|
<p>
|
|||
|
|
<ul>
|
|||
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#153">[ date ]</a><a href="index.html#153">[ thread ]</a><a href="subject.html#153">[ subject ]</a><a href="author.html#153">[ author ]</a>
|
|||
|
|
<!-- next="start" -->
|
|||
|
|
<li> <b>Next message:</b> <a href="0154.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0152.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
|||
|
|
<li> <b>In reply to:</b> <a href="0150.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|
|||
|
|
<!-- body="start" -->
|
|||
|
|
<i>> > If you are using SANE, you probably do so already. Most backends are</i><br>
|
|||
|
|
<i>> > implemented to spawn off a reader process, which communicates with the</i><br>
|
|||
|
|
<i>> > main (control) process via a pipe.</i><br>
|
|||
|
|
<p>
|
|||
|
|
<i>> Well, I'm not currently using SANE. I accept that if I am using a frontend</i><br>
|
|||
|
|
<i>> like GIMP then I have no right to expect 300DPI color images to go wizzing</i><br>
|
|||
|
|
<i>> by 2 per second.</i><br>
|
|||
|
|
<i>> However, I want to be able to write SANE front-ends that can drive my</i><br>
|
|||
|
|
<i>> back-end at those sorts of rates. </i><br>
|
|||
|
|
<p>
|
|||
|
|
I was never talking about SANE frontends. I was talking about putting a <br>
|
|||
|
|
TWAIN frontend in front of a SANE frontend. For security reasons (as<br>
|
|||
|
|
explained in my other mail), I'd rather implement that using a split-process<br>
|
|||
|
|
model.<br>
|
|||
|
|
<p>
|
|||
|
|
But I suppose for the application you have in mind, this is of no concern<br>
|
|||
|
|
anyway, as any bridging is to be avoided anyway, and it involves more effort<br>
|
|||
|
|
to make automated scans using TWAIN as compared to SANE anyway.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> I have put considerable effort into making sure the kernel mode device </i><br>
|
|||
|
|
<i>> driver does *not* copy lots of image buffers around (app mmaps the image </i><br>
|
|||
|
|
<i>> buffer which the card can access via DMA) and I don't want to see a SANE </i><br>
|
|||
|
|
<i>> standard that does gratuitous copies.</i><br>
|
|||
|
|
<p>
|
|||
|
|
SANE does not feature an interface that is _that_ direct. Sane images always<br>
|
|||
|
|
go through sane_read. That is to say:<br>
|
|||
|
|
<p>
|
|||
|
|
You SANE backend would be able to mmap that buffer, but the frontend would<br>
|
|||
|
|
still have to sane_read it in to work with it. This does not involve a pipe,<br>
|
|||
|
|
but means an extra memory copy. (I do not think that giving access to backend<br>
|
|||
|
|
internal buffers is a good idea in general, as it will quickly require <br>
|
|||
|
|
quite some management overhead in the frontends to compensate for different <br>
|
|||
|
|
formats such internal buffers can have.)<br>
|
|||
|
|
<p>
|
|||
|
|
Now it depends on what you actually want to do with the images: <br>
|
|||
|
|
<p>
|
|||
|
|
If you want to process or store them in any way, I expect that extra copy <br>
|
|||
|
|
to be of no concern. <br>
|
|||
|
|
<p>
|
|||
|
|
However if you will only be transferring them on a very high speed link <br>
|
|||
|
|
(>100Mbit), this might pose a problem.<br>
|
|||
|
|
<p>
|
|||
|
|
memcpy should work at over 100MB/sec on the systems you target, so I suppose<br>
|
|||
|
|
it would be neglegible as long as the outgoing link is at less than 10MB/sec<br>
|
|||
|
|
or the processing takes more than about 50 CPU cycles per pixel.<br>
|
|||
|
|
<p>
|
|||
|
|
CU, ANdy<br>
|
|||
|
|
<p>
|
|||
|
|
<pre>
|
|||
|
|
--
|
|||
|
|
= Andreas Beck | Email : <<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>> =
|
|||
|
|
<p>
|
|||
|
|
<pre>
|
|||
|
|
--
|
|||
|
|
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
|||
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
|||
|
|
</pre>
|
|||
|
|
<!-- body="end" -->
|
|||
|
|
<p>
|
|||
|
|
<ul>
|
|||
|
|
<!-- next="start" -->
|
|||
|
|
<li> <b>Next message:</b> <a href="0154.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0152.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
|||
|
|
<li> <b>In reply to:</b> <a href="0150.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|