Re: [AD] OS X full screen resize (was Re: Allegro 5 TODOs (from wiki)) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] OS X full screen resize (was Re: Allegro 5 TODOs (from wiki))
- From: Evert Glebbeek <eglebbk@xxxxxxxxxx>
- Date: Sat, 13 Dec 2008 10:04:23 -0500
On 13-Dec-08, at 4:36 AM, Milan Mimica wrote:
Uh? Doesn't ex_threads2 draw to the display from 6 different threads
and none of
them created the display, and it still works?
That's what I thought it did too, but no. That's not what it does. All
threads draw to their own memory bitmaps, which are drawn to the
screen in the main loop.
al_set_current_display() will make the context current to the thread
calling the
function, using pretty much the same routines on all three platforms:
glXMakeCurrent/wglMakeCurrent/makeCurrentContext
Hmm.
Ok, this is weird. I'm not quite sure what I was doing differently
before, but trying it again now it does actually work. :-/
Odd. I guess that comment is outdated then and my claim that it didn't
work due to some messup somewhere.
That shouldn't matter really.
No, but it would if the context wasn't set as current in the thread
that was transfering the bitmaps - which I guess is more or less what
I was trying to say.
That also suggests that my fix to get destroy_display() to not crash
on fullscreen displays under OS X isn't entirely correct and may only
work if the display that is destroyed is set as "current" in the
calling thread. Without a second display that's hard to test, but I
can make the destroyed display current while the cleanup operations
are performed and then switch it back to the previous state. In that
case, the loop transferring the bitmaps can go back into
destoryDisplay as well.
I'll have a look at it this afternoon.
Evert