kopia lustrzana https://gitlab.com/sane-project/website
108 wiersze
5.2 KiB
HTML
108 wiersze
5.2 KiB
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>> Why not write to a single file (every third byte, for example), and on</i><br>
|
|
<i>> each other pass, read a bufferful from the file, add in the bytes from</i><br>
|
|
<i>> 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 --> buffer --> 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>> In combination with the ``reserve space for the header'' idea I</i><br>
|
|
<i>> mentioned before, this would never use more space than the resulting</i><br>
|
|
<i>> image file.</i><br>
|
|
<p>
|
|
<i>> Whenever separate files are used, you'll at least double the size of</i><br>
|
|
<i>> the space required.</i><br>
|
|
This might be difficult in some places ... Imagine<br>
|
|
scanimage ... | ppmtosomething >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>> DM> To me, it seems like we should use memory/swap-space when it</i><br>
|
|
<i>> DM> looks like the image might fit in the available memory/swap-space</i><br>
|
|
<i>> DM> and use temporary files otherwise. E.g., on Linux, we could base</i><br>
|
|
<i>> DM> this decision on MemTotal: as reported in /proc/meminfo.</i><br>
|
|
<p>
|
|
<i>> I dislike this sort of decision making... by Murphy's law, it will</i><br>
|
|
<i>> 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>> You have to write to disk *sometime*, and if it doesn't take any</i><br>
|
|
<i>> 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>> Heck, I'll even help with implementation if that's the extra push</i><br>
|
|
<i>> 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 : <<a href="mailto:becka@sunserver1.rz.uni-duesseldorf.de">becka@sunserver1.rz.uni-duesseldorf.de</a>>
|
|
<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>
|