CyberShadow
ae.utils.graphics => renaming .w / .h to .width / .height?
So I've been an ae.utils.graphics user and I don't have much complaints.
I know it is a breaking change and not very important, but .w and .h look a tiny bit terse to me.
I'd like to do one more iteration of the graphics package with better range support (exposing the image as a range of rows, or range of pixels) so it's interoperable with std.algorithm and allows streaming image data, so I'll probably fold this change in there.
More suggestions:
- use only one multiply in
Image.scanline()instead of two: the common sub-expression isn't easy to merge, and I've found this function takes significant time in benchmarks.ImageRefdoesn't have this problem. (trivial) - draw primitives with integer coordinates are not that useful. For a renderer I found that most often I want float coordinates and I rarely want non-AA versions. (lot of work)
use only one multiply in Image.scanline() instead of two: the common sub-expression isn't easy to merge, and I've found this function takes significant time in benchmarks. ImageRef doesn't have this problem. (trivial)
Fixed
draw primitives with integer coordinates are not that useful. For a renderer I found that most often I want float coordinates and I rarely want non-AA versions. (lot of work)
Making the functions templated might Just Work in many cases. How about fixing this as needed?
Making the functions templated might Just Work in many cases. How about fixing this as needed?
You are right.
I've also noticed some naming/consistency problem in aaXXXX vs XXX nomenclature. Please don't take it too seriously because I'll be super picky here, because in general I've been more than content with ae.utils.graphics. But it's so good one can't help to notice :)
- softRing, softCircle and softRoundShape work with float coordinates but do not have the "aa" prefix. Which is probably because non-AA methods would be pretty undesirable indeed. I'd prefer "aa" names for those.
- aaHline/aaVline/aaFillPoly don't exist (being pedantic)
In general I could live with the "aa" primitives having the default shorter name and the integer version having the longer names (reverse then current), or not even existing publicly. Overloading by coordinates format, could be nice but I fear for readability. Though it works well for CHECKED.
No disagreements there. I'm actually not a fan of CHECKED though, because default parameters (template or not) don't stack. It's a holdover from ancient D1 code. Maybe it can be replaced with a Painter(bool checked) "namespace" (struct with static methods) that can be used like with (uncheckedPainter) { ... } OSLT, with aliases to the checked variant on the module level.