[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
What if you tied the function that called proc in with
release_screen?
--- Peter Wang <tjaden@xxxxxxxxxx> wrote:
> On 2005-10-04, Dustin Dettmer <dustin@xxxxxxxxxx>
> wrote:
> > What are the plans for implementing this? Is
> there
> > already some API decided upon?
>
> We won't do anything about that in 4.2.
>
> > How would this function sound?
> > int install_resizer(int (*proc)(int w, int h));
> >
> > proc would be passed the new w / h and could pass
> > non-zero to approve the change or 0 to deny the
> > change. If the change was approved, the screen
> bitmap
> > would be reallocated to the correct size and the
> > SCREEN_* would be fixed to evaluate to the correct
> > values.
>
> This kind of proposal has come up before and it's
> not enough. `proc' is
> presumably called from an auxiliary thread, in which
> case the screen can
> be resized at any time[1]. You need a function for
> the main thread to
> acknowledge the resize, and delay any resizing
> operation until that
> function has been called. Otherwise this piece of
> code is wrong:
>
> blit(bmp, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H);
>
> The screen could be resized between the time you get
> the SCREEN_W/H
> values and the time that blit() is called.
>
>
> For the new_api_branch, AL_DISPLAYs are event
> sources. When the user
> tries to resize a window, the AL_DISPLAY will
> generate a "resize
> request" event, which is entered into an event
> queue. When the program
> receives the event it can acknowledge the resize
> request, at which time
> the resize will actually take place. That's my
> idea, at least.
>
> Peter
>
> [1] Unless you allow `proc' to block until it is
> ready for the resize to
> occur, but that is even trickier.