[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Tuesday 21 December 2004 03:28 pm, Jon Rafkind wrote:
> >> So the user should destroy and recreate the screen bitmap in the user
> >> defined callback? In one sense this is better becuase then the user
> >> can alter screen as they please and not have any race conditions
> >> where screen is destroyed or equal to NULL, but in another sense
> >> maybe the user needs to know to much about screen?
> >
> > I don't really understand what you're thinking of. Example?
>
> Well in my code I was getting race conditions if I didnt do
> acquire_screen/release_screen. If my drawing loop is
> if ( draw ){
> // RESIZE HAPPENS NOW
> blit( buffer, screen, 0, 0, 0, 0, buffer->w, buffer->h );
> }
> Then screen will be destroyed and blit will blit to a null object. If
> the user has control over when screen is destroyed and created again,
> then it could go something like:
>
> if ( draw ){
> if ( resize ){
> resize = 0;
> recreate_screen( new_x, new_y );
> destroy_bitmap( buffer );
> buffer = create_bitmap( screen->w, screen->h );
> drawStuff( buffer );
> }
> blit( buffer, screen, 0, 0, 0, 0, buffer->w, buffer->h );
> }
Ok, so presumably the `resize' variable here is a way for Allegro to
communicate to the user that a resizing operation was requested. Then the
`recreate_screen' function is the acknowledgement from the user to allow
Allegro to make whatever changes to `screen' (and its subbitmaps, etc.).
This is basically the same idea that I wanted to apply to the new gfx API,
and also Bob's check_for_resize idea.
i.e. it's not callback-based any more -- good.
> > PS. To be honest, I don't think resizing should be added to the
> > current API. Also, callback-based designs are being phased out
> > because of all the troubles they cause with threads.
>
> I can see how resizing doesnt really fit with the current API, but I
> think it could be worked in.
Sure, but 4.2.0 looms.
> callbacks wont go away till at least 4.2.0,
> right? Additional functionality that uses callbacks should be able to go
> into the current API.
We can't do anything about the existing callback-based designs, but we should
cut our losses. Anything we add now will live on in the compatibility layer.
Peter