Re: [GnomeMeeting-devel-list] Win32 fullscreen

[Julien PUYDT <jpuydt free fr>]

Michael Rickmann a �it :
> Hello everybody,
> I found out why returning from fullscreen in win32-Ekiga is/was still a 
> hazard: A Windows window is not only owned by the process but also by the 
> thread which has created it. A different thread can change the Show 
> properties of that window but cannot destroy it.

Wonderful !

> gm_main_window_update_video in src/gui/main.cpp is used by two threads, at a 
> different frequency though. When SDL_Init+SDL_SetVideoMode is executed by one 
> thread and SDL_Quit by the other, SDL shuts down, but Windows forbids to 
> destroy the SDL_app window. Why can I reliably remove that window by 
> disconnecting ? I have not found the reason yet in the code. I suspect that 
> both threads terminate and Windows in due corse destroys the window owned by 
> one them.
> I have attached two patches which try to circumvent this circumstance without 
> changing the code too much. The first one is minimal, the second does the 
> same but uses the WinMain function in SDLmain.a. For me they fix the hung 
> SDL_app Window. But they do not address the problem which arises from the 
> SDL_app Window being destroyed at presumed thread termination. If the calling 
> state changes to stanby during fullscreen the window is destroyed, SDL_Quit 
> is called but during the following calls SDL cannot open the fullscreen 
> window again.
> From a user's point of view this behaviour is tolerable, I think. When 
> programming, however, I still try to find sort of a housekeeping thread in 
> Ekiga which could do the SDL_Inits+SDL_SetVideoMode and SDL_Quits and let the 
> others do the drawing. I have not been long enough with Ekiga to be really 
> aquainted with its design. Any hints are welcome.


Hmmmm... to circumvent the threading issue, the most efficient way is 
probably to create/destroy the SDL window through g_idle_add : that way 
it will be done in the mainloop thread.

Snark