Re: [AD] No more video/system bitmaps

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Tuesday 21 June 2005 21:14, Elias Pschernig wrote:
> In the current allegro, where it is just an int, I think it
> makes sense as a prameter. In 4.3.x, where it is a complicated struct, I
> think it makes more sense as state.

Well, that's true. I guess one would pass a pointer, but that still gets to 
be annoying...

> there are so many state variables still in use (some even by the
> software mouse drawer) that multi-threading is no argument..

You mean, no argument for the current API. But that doesn't mean it has to 
be like that for the new one.

> Even if you have display objects with the state instead of bitmaps, it
> won't change anything with respect to multi threading.

Let's keep a few things clearly seperated:

the current API is not thread-safe and you need to pass it a destination 
anyway. It's beside the point I was trying to make though, which was about 
drawing to *multiple displays*.

At that point, it makes sense to have *multiple* states, if multiple 
threads want to draw things to different displays.

The distinction I was trying to make is not between `displays or bitmaps' 
but between `one state for the whole programme' or `multiple states and 
select which one you use'.

> You either need 
> to pass the display object to every drawing function, or else do
> locking, or use per-thread variables.

As I said, pass the display object to the drawing function.

Evert