Hi,
On Mon, Jul 18, 2011 at 1:37 PM, Cyril Hrubis metan@ucw.cz wrote:
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.
"Hate" is not right. If there is such a word, I would hesitate to write it down.
[with curiosity replacing loathing for a moment] How is 19bpp used/divided? And what hardware? Is it on 19bit Harvard-type processors supporting ternary arithmetic while driving on the left side of the road?
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.
Thanks, Tomas