Hi!
Jo: prosim pana teto konference, aby nastavil 'Reply To' u mailu na gfxprim@ucw.cz; lepe se pak odpovida.
Should be fixed now.
It definitely makes sense to have transforming+clipping versions of operations as well as "bare" unsafe variants. I would propose to remove the "T" prefix from transforming variants, as most users will want the transforming behavior and to modify the names of the "bare" functions. I would propose "GP_Line_" or "GP_Line_Bare". What do you think?
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...
The transformed functions are costy for putpixels and blits, not sure how much (it's probably the same O() just different constant).
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.