The problem arises, if you want to pipe the output to another program.
In this case you have to do something like this :
scan-data --> buffer --> pipe
What should be used by that buffer has been discussed (in conjunction
with a similar topic) on the GIMP mailing list recently.
The outcome was as it was to be expected : The optimum solution depends
on your system.
So I vote for it being configureable, though I don't have the time to
implement it. The point about using MMAP instead of your scheme is,
that it can be done with exactly the same code that would be used for
a malloced buffer. Only start (malloc/mmap) and end (free/unmap) would
differ.
> In combination with the ``reserve space for the header'' idea I
> mentioned before, this would never use more space than the resulting
> image file.
> Whenever separate files are used, you'll at least double the size of
> the space required.
This might be difficult in some places ... Imagine
scanimage ... | ppmtosomething >outfile
This will require two files to be on disk simultaneosly plus probably a
working copy in memory which the PPMtools use.
There is no real good solution to the dilemma, as it depends on your
configuration _and_ on the rest of the pipe, if memory or file is
desireable.
> DM> To me, it seems like we should use memory/swap-space when it
> DM> looks like the image might fit in the available memory/swap-space
> DM> and use temporary files otherwise. E.g., on Linux, we could base
> DM> this decision on MemTotal: as reported in /proc/meminfo.
> I dislike this sort of decision making... by Murphy's law, it will
> make bad decisions in at least a few circumstances.
I quoted one above. Scanimage would use up the swapspace and ppmtosth
would die, if it tried to alloc another image that big. Let the user
choose.
> You have to write to disk *sometime*, and if it doesn't take any
> additional space, it might as well be during scanning.
Well - it does, if you want to save in another (more compact) format
anyway, but ...
> Heck, I'll even help with implementation if that's the extra push
> that's needed to convince any skeptics. :)
Yeah - do it. Make it configureable so you can do malloc(),mmap() and
normal file-io.
Ah - and try to put it in a seperate source file, as more than one backend
might want to use it.
CU,Andy
-- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de>
-- Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/ To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com