sane-project-website/old-archive/1997-05/0039.html

<!-- received="Thu May 29 08:16:45 1997 MST" -->
<!-- sent="Thu, 29 May 1997 12:44:14 +0200 (MET DST)" -->
<!-- name="becka@sunserver1.rz.uni-duesseldorf.de" -->
<!-- email="becka@sunserver1.rz.uni-duesseldorf.de" -->
<!-- subject="Re: image buffering" -->
<!-- id="m0wX2go-000BVRC@charon.beck-sw.de" -->
<!-- inreplyto="8667w3qdbu.fsf@localhost.profitpress.com" -->
<title>sane-devel: Re: image buffering</title>
<h1>Re: image buffering</h1>
<a href="mailto:becka@sunserver1.rz.uni-duesseldorf.de"><i>becka@sunserver1.rz.uni-duesseldorf.de</i></a><br>
<i>Thu, 29 May 1997 12:44:14 +0200 (MET DST)</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#39">[ date ]</a><a href="index.html#39">[ thread ]</a><a href="subject.html#39">[ subject ]</a><a href="author.html#39">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0040.html">Mark Cornick: "xcam/xscanimage hangs w/ SANE 0.57"</a>
<li> <b>Previous message:</b> <a href="0038.html">Michael K. Johnson: "Re: image buffering"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0042.html">Gordon Matzigkeit: "Re: image buffering"</a>
<li> <b>Reply:</b> <a href="0042.html">Gordon Matzigkeit: "Re: image buffering"</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
<i>&gt; Why not write to a single file (every third byte, for example), and on</i><br>
<i>&gt; each other pass, read a bufferful from the file, add in the bytes from</i><br>
<i>&gt; the scanner, and write the bufferful back to the file. </i><br>
This is a feasible solution. The buffering problem only comes up, if the<br>
frontend doesn't save to file (which it could do in-situ for simple<br>
formats exactly the way you described).<br>
<p>
The problem arises, if you want to pipe the output to another program.<br>
In this case you have to do something like this :<br>
<p>
scan-data --&gt; buffer --&gt; pipe<br>
<p>
What should be used by that buffer has been discussed (in conjunction<br>
with a similar topic) on the GIMP mailing list recently.<br>
The outcome was as it was to be expected : The optimum solution depends<br>
on your system.<br>
<p>
So I vote for it being configureable, though I don't have the time to<br>
implement it. The point about using MMAP instead of your scheme is, <br>
that it can be done with exactly the same code that would be used for<br>
a malloced buffer. Only start (malloc/mmap) and end (free/unmap) would<br>
differ.<br>
<p>
<i>&gt; In combination with the ``reserve space for the header'' idea I</i><br>
<i>&gt; mentioned before, this would never use more space than the resulting</i><br>
<i>&gt; image file.</i><br>
<p>
<i>&gt; Whenever separate files are used, you'll at least double the size of</i><br>
<i>&gt; the space required.</i><br>
This might be difficult in some places ... Imagine<br>
scanimage ... | ppmtosomething &gt;outfile<br>
This will require two files to be on disk simultaneosly plus probably a <br>
working copy in memory which the PPMtools use.<br>
<p>
There is no real good solution to the dilemma, as it depends on your <br>
configuration _and_ on the rest of the pipe, if memory or file is <br>
desireable.<br>
<p>
<i>&gt;  DM&gt; To me, it seems like we should use memory/swap-space when it</i><br>
<i>&gt;  DM&gt; looks like the image might fit in the available memory/swap-space</i><br>
<i>&gt;  DM&gt; and use temporary files otherwise.  E.g., on Linux, we could base</i><br>
<i>&gt;  DM&gt; this decision on MemTotal: as reported in /proc/meminfo.</i><br>
<p>
<i>&gt; I dislike this sort of decision making... by Murphy's law, it will</i><br>
<i>&gt; make bad decisions in at least a few circumstances.  </i><br>
I quoted one above. Scanimage would use up the swapspace and ppmtosth<br>
would die, if it tried to alloc another image that big. Let the user<br>
choose.<br>
<p>
<i>&gt; You have to write to disk *sometime*, and if it doesn't take any</i><br>
<i>&gt; additional space, it might as well be during scanning.</i><br>
Well - it does, if you want to save in another (more compact) format<br>
anyway, but ...<br>
<p>
<i>&gt; Heck, I'll even help with implementation if that's the extra push</i><br>
<i>&gt; that's needed to convince any skeptics. :)</i><br>
Yeah - do it. Make it configureable so you can do malloc(),mmap() and<br>
normal file-io.<br>
<p>
Ah - and try to put it in a seperate source file, as more than one backend<br>
might want to use it.<br>
<p>
CU,Andy<br>
<p>
<pre>
-- 
Andreas Beck              |  Email :  &lt;<a href="mailto:becka@sunserver1.rz.uni-duesseldorf.de">becka@sunserver1.rz.uni-duesseldorf.de</a>&gt;
<p>
<pre>
--
Source code, list archive, and docs: <a href="http://www.azstarnet.com/~axplinux/sane/">http://www.azstarnet.com/~axplinux/sane/</a>
To unsubscribe: mail -s unsubscribe <a href="mailto:sane-devel-request@listserv.azstarnet.com">sane-devel-request@listserv.azstarnet.com</a>
</pre>
<!-- body="end" -->
<p>
<ul>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0040.html">Mark Cornick: "xcam/xscanimage hangs w/ SANE 0.57"</a>
<li> <b>Previous message:</b> <a href="0038.html">Michael K. Johnson: "Re: image buffering"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0042.html">Gordon Matzigkeit: "Re: image buffering"</a>
<li> <b>Reply:</b> <a href="0042.html">Gordon Matzigkeit: "Re: image buffering"</a>
<!-- reply="end" -->
</ul>