std.algorithm for images

Adam D. Ruppe destructionator at gmail.com
Mon Apr 11 09:06:58 PDT 2011


spir wrote:
> I intend to do some trials with simpledisplay. This could also
> provide for a few unittests. Are you interested in that?

Yeah, sounds good.

> What is the advantage of laziness here (both for input and output)?
> One needs to compute the while pic anyway... Actually simple ranges
>(aven simple arrays?) would do the job as well, wouldn't they?

The main reason I went this way was to be like the rest of Phobos.
Why does Phobos use laziness so much?

One big reason is you can always go from lazy to eager, but not
the other way around. Just call array() on it.

Lazy computations can also save on a lot of memory if you don't
need the whole thing at once, especially if it's very large.
One situation this might be useful is working with video. Hopefully,
the lazy algorithms for images will be reusable for a streaming
video too. My StaticGenerator there could do any size without
taking more than the memory needed for a single line.

Finally, there might be a small speed boost, since it lets you
mix CPU and disk operations together - load part of the file, then
process it while the next part is still coming off the disk, instead
of having the processor sit idle while waiting for it to load. It
could also cut down on memory allocations by reusing buffers
too. (My implementation doesn't realize this very well, but it
could be done in theory. However, a part of me isn't sure it's
a great idea... mutable buffers in std.stdio.File wasted some
time yesterday because I forgot to copy them... but still, it's
possible to do more this way.)

> For instance, I'd like a fill(shape,fillColor) function working
> for any (closed) shape

Yes, indeed.


More information about the Digitalmars-d mailing list