Hi!
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.
For >=8bpp types, you can just set the base pointer to the new "top-left" corner and change the size preserving bytesperrow. Voila - subcontext.
The only problem were subpixel types - there the pionter would also need to have "pixel offset". Per-bpp functions can ignore it altogether for >=8bpp, but it still creates some mess. Both "normal" and "Raw" functions accessing the context should do this "shifting". Should it be done in PutPixel or GP_PIXEL_ADDR/OFFSET (more general and probably right, but even messier)?
Well I know you hate to hear that, but there are really > 8BPP byte unaligned pixel types 19BPP for example (which is supported by linux on arm targets and yes I have such hardware). But the solution should be the same as for subbyte pixels.
I will see whether I manage to include that into generate (my time-schedule is very stretched for few weeks now), but feel free to add subcontexts for >=8bpp for now. It may be wise to remove the old clipping at the same time. This would disable changing <8bpp clipping but that may be ok for now (for generate).
Okay, I'll do the preparations and function to create subcontext for byte-aligned pixels.