Re: [AD] OS X full screen resize (was Re: Allegro 5 TODOs (from wiki))

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 11 Dec 2008, at 11:00, Peter Hull wrote:
> > (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).
> That's the normal way to do it, from Apple's sample code. In Windowed
> mode, the message loop is handled internally through the responder
> chain (NSView is a subclass of NSResponder) However in fullscreen
> there's no view as such so it's necessary to receive and dispatch
> events explicitly.

Sure; it's a valid enough distinction - there's no logcal reason one  
shouldbe like the other at all. There's a lot of code that's similar  
between the windowed and fullscreen code but subtly different and I  
got confused a couple of times while trying to follow what's going  
on. It probably doesn't help that the fullscreen and windowed code  
are currently mixed among eachother and it may be better to separate  
the code more clearly in "shared code", "windowed mode code" and  
"fullscreen mode code". Admittedly, there's also something to be said  
for having similar functions for both in subsequent pairs, but I  
don't think that's entirely consistently done at the moment (from  
memory, I might be wrong).

Not bashing your code, by the way. :)

> I thought it's possible to have a context current in more than one
> thread, maybe I'm wrong.

I get the impression (from Peter W's post) that it should be possible  
to call drawing operations from other threads, but it's clearly not  
working at the moment, at least on OS X.
Personally, I think my fix (moving the bitmap-relocation code into  
destroy_display) is the correct way to do it because it's robust and  
simple, but it does subtly break the design objective of putting  
create/destroy operations on the main thread (subtly, nothing is  
destroyed in transferring the bitmaps to another display). So an  
alternative fix might be to make it possible reuse the context from  
another thread.

About transferring bitmaps to another display: shouldn't there be  
some sort of mutex lock when doing that, in case a background thread  
is modifying the same list of bitmaps at the same time? Maybe some  
sort of mutex that optionally blocks access to the list of video  
bitmaps for that particular display? Or is that not needed if you  
can't draw to a display from another thread?

Evert