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: Wed, 10 Dec 2008 22:31:32 -0500
Ok, nailed it!
Well, the crashing bit anyway.
The problem has to do with destroyDisplay, which does the actual job
of transfering the bitmaps from one display to another. However, this
function is called as
[ALDisplayHelper performSelectorOnMainThread:
@selector(destroyDisplay:)
withObject: [NSValue valueWithPointer:dpy]
waitUntilDone: YES];
which means it can (does?) run on another thread (by the way, I don't
fully understand the way the full screen OS X code works; it runs its
own event loop and is subtly different from the windowed mode in many
ways in a way that isn't always clear - this needs to be commented/
documented better). Now there's many more code in there that does
something similar, but there is an important difference: none of that
code does drawing operations, whereas this code does. So if I get this
right (someone please correct me if I'm wrong), it's trying to do
drawing operations using a context that's current in another thread -
which isn't permitted.
Anyway, long story short, if I move the code that transfers the
bitmaps to another display (or converts them to memory bitmaps) is
called before destroyDisplay is called (there's no real reason it has
to be in there anyway), the crash is avoided and ex_fs_resize() works
correctly - when using video bitmaps. There's still the weird problem
with memory bitmaps.
I'll clean up the code and commit the fix for this problem, hopefully
tonight but it might be tomorrow.
Evert