On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev
wrote:
http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
Some highlights from a recent overhaul of the graphics package
from my D library. It makes use of a number of D-specific
language features, so I've tried to make the article accessible
to people new to D as well.
That's really cool. I have some notes though:
* All the function templates separate the template declaration
from the function declaration, when they can just use the
function template syntax.
* Any type is accepted for the colour type, even though certain
basic assumptions are made, such as the colour type being
assignable to itself.
* Image.w/h/pixels should probably be read-only properties in
the public interface.
* Any particular reason that coordinate integers are signed?
`isView` seems to prefer `size_t`.
* `Warp` should probably have a `if (isView!V)` constraint.
* `warp` exclusively uses string expression arguments...
* I'd recommend sticking to structs (often with AliasThis) over
mixins for as far as it goes, as it's much more structured, thus
easier to read and reason with.
* The most common style for template parameter names (Phobos
uses it, too) is just `Color`, not `COLOR`.
* I know "w" and "h" are common abbreviations used in C, but
they seem unnecessary in D - detrimental rather - if your code
examples are anything to go by.
It's always nice to know examples of high performance range-based
code. I noticed that the `View` concept does not have the concept
of stride or access to pixels using a single absolute coordinate;
maybe if that was the case, the `blitTo` algorithm could be
optimized to its conclusion, instead of copying scanlines one by
one.
