Hi,
Well, I still could imagine circumstances where non transformed functions are good to have, but you may say that I have very good imagination...
I would agree to keep them as "partially internal". Would you suggest a naming scheme?
Hmm, I personally preffer something like GP_RLine() (for Raw Line).
Now there is a good flame! Lets feed it a little:
I disagree with RLine - HLine is the name "Horizontal line", but raw/nonraw is orthogonal to that. I would hate to have [ridiculous example] "ATRHLine" for antialiased, translucent, raw and horizontal line. Compare with AA_HLine_RAW, HLine_AA_Raw or HLine_AR (as one-letter flags, but still prune to collisions)
While having flags as non-separated prefixes seems tempting, it will lead to ambiguous names, order confusion etc.
In general, it is a good question which separate variants to generate for combinations of Antialiasing, Transparency and Raw(nontransformed).
Another general point is that we might want to split drawing functions off core to a different "module", keeping putpixel and perhaps writepixels.
I would also prefer to keep the core library as simple as possible, and have somewhat "modular" layout (context should be usable without text, images, events and backends).
True indeed. I was thinking of this too, we IMHO have too much functionality in core now. At least I would move the text related code to it's own directory.
Agree.
I was thinking about adding "transformed w/h" to GP_Context to speed up GP_ContextW (avoid swap_axes checking), but that is probably not useful and can be added later.
I understand that, but there are at least two more problems with that:
- having two w/h is confusing
- with two w/h context could be in inconsistent state
- you must add number of checks into the code
I understand that having two public attributes would be confusing, but if we really want to keep it "secret", then I do not see the confusion problem.
How would you get inconsistency in GP_Context? Context and its attributes are once set-up on context creation and then never modified again (only clipping may be modified afterwards).
Inconsistency can either be introduced upon creation - either in core lib (we can have a debug check tests there) or manual initialization (should be forbidden); or by modification afterwards - either manually (if anybody modifies these, no CHECKs can save her from doom) or by memory corruption (then the CHECK is useless anyway and not much more informative that SEGV).
It is a pity that C does not have const struct members as C++ classes do.
T.