kopia lustrzana https://gitlab.com/sane-project/website
109 wiersze
5.1 KiB
HTML
109 wiersze
5.1 KiB
HTML
<!-- received="Wed May 28 18:43:03 1997 MST" -->
|
|
<!-- sent="28 May 1997 19:25:25 -0600" -->
|
|
<!-- name="Gordon Matzigkeit" -->
|
|
<!-- email="gord@m-tech.ab.ca" -->
|
|
<!-- subject="Re: image buffering" -->
|
|
<!-- id="199705281624.JAA07110@panda.mosberger" -->
|
|
<!-- inreplyto="Wed, 28 May 1997 09:24:54 -0700" -->
|
|
<title>sane-devel: Re: image buffering</title>
|
|
<h1>Re: image buffering</h1>
|
|
<b>Gordon Matzigkeit</b> (<a href="mailto:gord@m-tech.ab.ca"><i>gord@m-tech.ab.ca</i></a>)<br>
|
|
<i>28 May 1997 19:25:25 -0600</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#32">[ date ]</a><a href="index.html#32">[ thread ]</a><a href="subject.html#32">[ subject ]</a><a href="author.html#32">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0033.html">Gordon Matzigkeit: "Re: HP support"</a>
|
|
<li> <b>Previous message:</b> <a href="0031.html">David Mosberger-Tang: "Re: image buffering"</a>
|
|
<li> <b>In reply to:</b> <a href="0031.html">David Mosberger-Tang: "Re: image buffering"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
Hi!<br>
|
|
<p>
|
|
<i>>>>>> David Mosberger-Tang writes:</i><br>
|
|
<p>
|
|
[...]<br>
|
|
Mathias> swapspace) and I think not many people on Linux have. David<br>
|
|
Mathias> mentioned that a temporary file wouldn`t be a nice solution.<br>
|
|
Mathias> Here is my question: Why not ? Shouldn't it be possible to<br>
|
|
Mathias> write three temporary files for the red, green and blue<br>
|
|
Mathias> frame (of course not as image but the red bytes in a<br>
|
|
Mathias> line...) so that each will consume 1/3 of the entire image<br>
|
|
Mathias> in space? After the last pass the picture can be put<br>
|
|
Mathias> together from those three files and send to stdout or file.<br>
|
|
<p>
|
|
DM> It's certainly possible. Michael suggested using mmap'ing to<br>
|
|
DM> provide backing store in the filesystem instead of the<br>
|
|
DM> swap-space. Of the two solutions, I think mmap is technically<br>
|
|
DM> preferable when there is plenty memory available. On the other<br>
|
|
DM> hand, mmap is still quite a portability nightmare, so using<br>
|
|
DM> regular files might still be better, overall.<br>
|
|
<p>
|
|
Why not write to a single file (every third byte, for example), and on<br>
|
|
each other pass, read a bufferful from the file, add in the bytes from<br>
|
|
the scanner, and write the bufferful back to the file. This would be<br>
|
|
a close alternative to mmap (which you could still use on systems that<br>
|
|
have it implemented correctly).<br>
|
|
<p>
|
|
In combination with the ``reserve space for the header'' idea I<br>
|
|
mentioned before, this would never use more space than the resulting<br>
|
|
image file.<br>
|
|
<p>
|
|
Whenever separate files are used, you'll at least double the size of<br>
|
|
the space required.<br>
|
|
<p>
|
|
DM> However, the real issue is: what if you have tons of<br>
|
|
DM> memory/swap-space but not much free diskspace? Don't say that<br>
|
|
DM> doesn't happen.<br>
|
|
<p>
|
|
Okay, I won't. ;)<br>
|
|
<p>
|
|
Seriously, with the above scheme (either mmapping or writing to a<br>
|
|
single file and using a separate in-memory buffer), the question of<br>
|
|
disk space is moot. If anything, your large memory should be used by<br>
|
|
the kernel to help cache this file and save the price of disk i/o.<br>
|
|
<p>
|
|
DM> To me, it seems like we should use memory/swap-space when it<br>
|
|
DM> looks like the image might fit in the available memory/swap-space<br>
|
|
DM> and use temporary files otherwise. E.g., on Linux, we could base<br>
|
|
DM> this decision on MemTotal: as reported in /proc/meminfo.<br>
|
|
<p>
|
|
I dislike this sort of decision making... by Murphy's law, it will<br>
|
|
make bad decisions in at least a few circumstances. By using a<br>
|
|
constant in-memory buffer, the total space requirement will never<br>
|
|
exceed imagesize + reserved_header + buffersize. Otherwise, we're<br>
|
|
talking at least 2 * imagesize.<br>
|
|
<p>
|
|
You have to write to disk *sometime*, and if it doesn't take any<br>
|
|
additional space, it might as well be during scanning.<br>
|
|
<p>
|
|
FWIW, I'm a big fan of doing things in-place rather than copying back<br>
|
|
and forth. Memory and disk caching mechanisms are designed to handle<br>
|
|
this behaviour, so it might even be a performance gain, too.<br>
|
|
<p>
|
|
Heck, I'll even help with implementation if that's the extra push<br>
|
|
that's needed to convince any skeptics. :)<br>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Gord Matzigkeit | Proudly running pieces of the GNU operating system.
|
|
gord@m-tech.ab.ca | Jacques Cousteau loved programming in assembler.
|
|
<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="0033.html">Gordon Matzigkeit: "Re: HP support"</a>
|
|
<li> <b>Previous message:</b> <a href="0031.html">David Mosberger-Tang: "Re: image buffering"</a>
|
|
<li> <b>In reply to:</b> <a href="0031.html">David Mosberger-Tang: "Re: image buffering"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|