| Re: [AD] android_set_current_display |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Mon, Nov 5, 2012 at 9:35 AM, Jon Rafkind <workmin@xxxxxxxxxx> wrote:
> There is a bug in android_set_current_display where the new display will never be set properly. The short story is that it first checks if al_get_current_display() == dpy, where dpy is the argument to the function, and if they are equal then the function aborts (presumably to save time). But these two things will always be equal.
>
> With this client code:
>
> ALLEGRO_BITMAP * old = al_get_target_bitmap();
> al_set_target_bitmap(NULL);
> al_set_target_bitmap(old);
>
> The old->display will be the current active display. Setting the target to NULL will unset the current display. Then setting the target back to old will try to reset the display to old->display.
>
> The logic Allegro follows is
>
> al_set_target_bitmap(old)
> // tls.c: al_set_target_bitmap
> ...
> if (old_display != new_display){
> ...
> tls->current_display = new_display;
> new_display->vt->set_current_display(new_display)
>
> // android/android_display.c:android_set_current_display
> if (al_get_current_display() == dpy) return true;
>
> Where al_get_current_display() is
>
> // tls.c:al_get_current_display
> return tls->current_display;
>
> So al_get_current_display() will always be equal to the dpy parameter to android_set_current_display. By simply commenting out the check in android_set_current_display() and letting it always set the display (with make_current) my application works as expected. I guess I should mention that this bug eventually causes all opengl calls to fail because there is no context for them.
>
Other ports have no such check - so why does the Android port have it?