Re: [AD] System bitmap bug (fix)

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Which doesn't really make sense.

Unless proven wrong, we have to suppose that the decision was made
knowingly.

> The driver doesn't support system bitmaps but must still expose a
> look-alike functionality, which isn't fully interchangeable with memory
> bitmaps? This strikes me as unorthogonal, not to mention extra work.

No, it must only provide the method, which will be the same as the method
for memory bitmaps in almost (if not all) cases.

> The way I see it, we have several options of failing a
> create_system_bitmap() call:
>
> 1. Return NULL, like video bitmaps. Let the app figure it out. Not
> backward compatible though.

And it forces the user to write more code.

> 2. Return a Real Memory Bitmap (tm). The app can't tell the difference
> anyway (appart from blitting speed). Drivers which don't support system
> bitmaps don't need to expose any system-bitmap-related functions. This
> means that they don't need to support pass-through calls for
> fake-system-bitmaps. This also makes it consistent with the way Allegro
> handles drivers (unsupported calls just don't do anything, except for
> create_system_bitmap).

I think the following expression must always be true:
   bmp = create_system_bitmap(w, h), !bmp || is_system_bitmap(bmp);

> 3. Return a memory bitmap with the system-bitmap flag set. Frankly, I
> really don't see any advantage of using this method.

I don't see any decisive advantage either. But it is the current approach
and the burden of the proof is on the other solutions, not on this one.

--
Eric Botcazou