RE: [AD] sub bitmap patch

["Vincent Penquerc'h" <Vincent.Penquerch@xxxxxxxxxx>]

Title: RE: [AD] sub bitmap patch

> 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 don't believe so, as it will crash as well if you set the clipping
values to garbage. That is well outlined in the docs. If you mess with
the clipping values, it's at your own risk. I supply (undocumented,
I meekly agree) add_clip (get_clip being just a convenience function
to get rid of the confusing +-1 between set_clip and cl/cb) to make
sure clipping values are set to sane values (set_clip would destroy
them). I believe that is not so much dangerous as it was before. You
just have to pay attention not to draw outside the clipping rectangle,
as you HAD to do before. It just happened that if you didn't respect
them, you had less chance to draw outside your memory space, or on
other data. But this possibility has always existed.

> 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.

Might be interesting. Though probably of not much use: if you use
the regular drawing routines, they'll (hopefully) respect the clipping
values. If you go to the bare *lines, if you don't respect the values,
you won't respect "hard" values either. And this would have to not be
restricted to sub bitmaps: try creating a 64x64 (normal) bitmap, make
its clipping values to 0, 0, 128, 128, and then blit a 128x128 sprite
on it. It should crash. So you'd have to do that for all bitmaps, and
that'll slow down some drawing routines.

> 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.

Is that in the docs somewhere ? :)
For many types of bitmap, there are restrictions on direct use.
That is just another one. And it's a pretty innocuous one, as this
didn't even work in a consistent way before.

> 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.

OK.

--
Vincent Penquerc'h