Hi!
- The gfx part for now uses GP_PutPixel_Raw() (which is wrong because
we need to clip every pixel (at least for the more complicated shapes). So variant without transformation but with clipping is needed too.
Or better we should settle for subcontext and clipp ony for context boundaries. Shouldn't the Raw function clip at least for these?
I am in favor of subcontexts. However, I would expect Raw to be as raw(=fast) as possible. There are quite a few use-cases where the algorithm takes care of clipping (e.g. line drawing).
Hmm now we just need someone to get the subcontextes implemented, what was the problem with that? I remeber waguely there were some problems with not byte aligned pixel types.
Yes, at least for vertical lines it's quite easy to clip at the start (and we may have for example two alorithms for circle one with clipping and one without as figuring out if circle crosses some border is easy...)
We can easily have both versions. The biggest cost being consistency and confusion. What about the following:
- "normal" functions respect both transformations and clipping
(subcontext boundaries)
- "Raw" functions ignore transformations but clip on subcontext boundary
- "RawNoclip" (or similar, explicit name) ignore everything. The name
should explicitely indicate that danger. We will probably only have get/putpixel and maybe v/hline in this category.
Okay that sounds reasonable.