al_get_window_position is returning (0,0) on Ubuntu. The Allegro code looks like:

   ALLEGRO_DISPLAY_XGLX *glx = (ALLEGRO_DISPLAY_XGLX *)display;
   /* We could also query the X11 server, but it just would take longer, and
    * would not be synchronized to our events. The latter can be an advantage
    * or disadvantage.
    */
   *x = glx->x;
   *y = glx->y;

When do glx->x and glx->y get updated? Even the following fails (sets x and y to 0):

int sx, sy;
ALLEGRO_DISPLAY *display = al_get_current_display();
al_set_window_position(display, 100, 100);
al_get_window_position(display, &sx, &sy);

Also, why do al_get_window_position and al_set_window_position take a ALLEGRO_DISPLAY parameter when none of the other functions do?

Might be a problem if the request fails for some reason. Perhaps a better solution is to specify that al_set_window_position will work asyncronously, and some event will be posted when the actual move occurs? Or make al_set_window_position block until the move succeeds or fails.

I think it was like that already at one point. And I wouldn't mind.

I assume technically it just means replacing ALLEGRO_DISPLAY with ALLEGRO_BITMAP throughout the API. ALLEGRO_DISPLAY would only be an internal type then. And al_set_target_bitmap would set the current display to NULL except when the passed bitmap is the backbuffer of a display, in which case it would set that as the current display. Should be a quite simple change. A normal application like below would need no change at all:

al_create_display(1000, 1000);
al_draw_line(0, 0, 1000, 1000, 1);
al_flip_display();

Only where you use al_set_target_bitmap() right now and don't restore it to the backbuffer before calling a function operating on the current display a change is required in user code (for a single-display application).

There's much bigger breaking changes than that in 4.9.21 already

With Peter's suggestion you could not change the window title while an offscreen bitmap or memory bitmap is the drawing target. If we keep ALLEGRO_DISPLAY as separate type that would make no sense at all. The idea behind the suggestion was to to make things less confusing not more, so I'd say it implies getting rid of ALLEGRO_DISPLAY. If you can't set or query it nor pass to any functions, why confuse the user with exposing the type?

I think this change unnecessarily conflates display specific functionality with drawing, which is display independent. It also creates even more magical types than there are now...

I for one would prefer not to have the al_get_backbuffer functions at all, since the bitmaps returned by those functions are very limited (see the docs) and have al_set_target_bitmap(0) make the target bitmap be the backbuffer again (some special casing/functioning can be done for the frontbuffer). For using backbuffer as a source bitmap, I'd have a al_copy_from_backbuffer or something, since that's the only thing we can do right now anyway (everything else falls back to software routines).

As for where the current bitmap belongs... it doesn't really matter I suppose, both making it thread local (as it is now) and display local (as it actually is) are both workable solutions, since in the end, you can't use multiple displays in a single thread anyway.

I think the overwhelmingly common use case of the front buffer is for front buffer-only applications... I can't imagine right now a situation where it would make sense to use the front buffer when you have the back buffer already there.

I was against the blend color as a parameter .

I think the current breakdown of what is a state and what is not to be pretty good (I sort of like the color change, myself, although those tinted functions do look obnoxious).

No, I wouldn't want that, and I don't think it's necessary.

Yes, exactly. I'm wondering if we need the "current display" concept at all.

Ok, I think the problem is that the OpenGL rendering context is tied up with ALLEGRO_DISPLAY (which also deals with other things). What al_set_current_display really does is change the OpenGL rendering context. But al_set_target_bitmap also does it as necessary, by changing the current display...

Proposal:

• Remove al_set_current_display().

  
  

• Make functions take ALLEGRO_DISPLAY arguments where required, e.g.

    ALLEGRO_BITMAP *al_get_backbuffer(ALLEGRO_DISPLAY *display);
    void al_set_display_icon(ALLEGRO_DISPLAY *display, ALLEGRO_BITMAP *bmp);

• Remove al_get_current_display(), but replace it with al_get_target_display().
  This basically returns al_get_target_bitmap()->display;
  

• al_set_target_bitmap(video_bitmap) internally sets the OpenGL rendering context to the context of the display which owns the bitmap. If the rendering context is already the correct one, nothing happens. The user normally doesn't need to know about rendering contexts, but it useful to know for performance and unavoidable for multithreaded programs. So, no change from current behaviour.

  
  

• al_set_target_bitmap(NULL) immediately releases the OpenGL rendering context.
  This replaces al_set_current_display(NULL).
  

• al_set_target_bitmap(memory_bitmap) does not release the OpenGL rendering context, for performance reasons (although it probably doesn't matter). No change from current behaviour.
  

• al_destroy_display(display) implicitly calls al_set_target_bitmap(NULL) when al_get_target_bitmap()==display.

  
  

• [Not 100% sure] Rename al_flip_display() to al_flip_target_bitmap(). It swaps the front/back-buffers of the display that owns the target bitmap, if any. Otherwise does nothing.

Amendment:

• I've started implementing this, and found that al_set_target_bitmap(al_get_backbuffer(display)) occurs so often that a shorthand would be welcome, e.g. al_select_backbuffer(display) as mentioned above.

I think 99% of all A5 programs will use a single window. Especially in a game it probably won't feel good having more and also in applications it may be bad design. (Isn't it the main complaint about Gimp that it uses multiple windows?)

With that in mind in almost all cases there wouldn't be any confusion about the current display as it naturally would be the one existing display, over the lifetime of the application.

Only in the rare case where you have more than one display would you ever want to call al_set_current_display. No functions actually would need to take an explicit ALLEGRO_DISPLAY parameter. I think the confusion right now is only because some functions like al_get_window_position or al_acknowledge_resize or al_get_display_event_source use such a parameter when they aren't supposed to.

So I think fixing those three functions by adding the explicit parameter to all other functions isn't the ideal solution - I'd much rather simply remove it from them instead and use the current display.

However I don't feel strongly about it. Completely hiding ALLEGRO_DISPLAY indeed would go too far as in multi-window applications only being able to change it with al_set_target_bitmap would be confusing. So we need the ALLEGRO_DISPLAY type in which case we may as well pass it around.

I see. Probably also a rare case though. I wonder if the upcoming change can fix the technical troubles of the native dialogs addon... I don't think using the current display actually ever worked - here X11 seems to create detached windows (i.e. they go behind the A5 windows which they should not) anyway. Most likely would need to create the window from the same thread where the X11 window was created since X11 itself doesn't handle multiple threads so well.

the al_get_backbuffer function or one like it would have to take a ALLEGRO_DISPLAY arg.