Re: [AD] sub bitmap patch

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> However, the code does do something if the origin point does not lie
> within the parent region, but does the wrong thing. So I guess the
> behavior is actually undefined :)

I agree, the current behaviour (translating the sub-bitmap) is not very
good. And the one you're proposing is probably the right one. However, I
think your solution (as implemented in the patch) is not complete and may
prove dangerous: although you provide the get_clip() and add_clip()
functions (not very documented btw), an user may not understand their
purpose and modify the clipping of an "unusual" sub-bitmap, leading to a
SIGSEGV.

I think we need kind of a "hard clipping" for sub-bitmaps, against which
set_clip() would check the requested clipping rectangle and do the
intersection. The mechanism would be transparent to the user, no need for
get_clip() and add_clip() API functions.

Moreover, there is the problem of direct access to the scanlines: with the
current behaviour of create_sub_bitmap(), you are always guaranteed that
bmp->h scanlines of bmp->w pixels are valid for any sub-bitmap. This would
not be the case with your patch.

So I think we need a consistent framework in order to address all the
problems (including possible issues with video sub-bitmaps). IMHO definitely
too late for 4.0, but ok for 4.2 (or 5.2, I'm a little lost in this
numbering buzz ;-). I'll put it on the todo list.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx