Hi!
I agree with the transformed functions being the default. However, "_Bare" is uncommon and IMO difficult to understand. I'm not even sure if the untransformed functions need to be public. The time cost of transformation is only an issue for very basic functions like putpixel; even for lines it should already be negligible.
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).
We need to somehow fix the context behavior anyway, and the freedom we will retain by using accessors will be probably very small.
Depends on how much 'intelligence' we want to put into the context later. When I think about the API, I feel more and more inclined to adding more status fields - like current color, etc. - to the Context to keep the number of arguments to drawing functions relatively small; otherwise, we will need to pass more and more various style-related settings through arguments. But that's just my opinion.
When I use the API, I usually use like three or five colors at the time one for background, one for text and one or more for foreground. Following that, the context would need to contain Text Style and number of colors. Rather than that I prefer lightweight context to let the library user handle things himself.
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.
If you really think that having a "drawing context" with bg/fg color, font and others would be useful, you can make wrappers of all the drawing functions accepting that parameter, such as: drawing_context=GP_DC_New(context, aliasing, font, fgcolor, bgcolor, ); GP_DC_Line(drawing_context, x1, y1, x2, y2, GP_FGCOLOR); but IMO the general usefulness would be limited.
Yes modular could easily apply here.
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
In short, I don't think this is worth of the work.