Re: [GnomeMeeting-devel-list] Win32 fullscreen

[Michael Rickmann <mrickma gwdg de>]

Hi Julien,

On Monday 27 March 2006 16:47, Julien PUYDT wrote:
> Michael Rickmann a écrit :
> > ekiga_win32-1.patch just fixes the SDL hung window issue.
>
> I read that patch several times ; I don't really like it : it seems both
> too complex and too intrusive. I would like more explanations to

I fully agree, so let us make things simpler. First the facts - only for Win32 
spoken. 
1) SDL switching has to be done in the same thread, we aggreed on the GLib 
main event loop for that.
2) So we have two drawing threads (I checked that) and a manager thread which 
reacts a bit sluggish and switches during idle.
3) The drawing threads must not write to the SDL surface before it is created 
or after it starts to be destroyed.
4) The drawing threads may send output to the GTK+ window at any time as long 
as it exists hidden or not.
5) The manager may be interrupted at any time.
6) The drawing threads cannot be interrupted by the manager, because the 
manager only runs during idle.
7) The manager may be queued several times simultanously through several 
switching requests.

So the manager has to switch some guide post - a variable - for the workers 
that they know where to draw. Currently there are several variables in 
Ekiga's code which contain information whether fullscreen or not.
a) mainwindow's mv->screen, b) VIDEO_DISPLAY_KEY "zoom_factor", c) 
display_type, d) fs_active. a) and b) are globally accessible, c) and d) 
local to gm_main_window_update_video. Of course we have to take a) or b) for 
our guide post. I had chosen VIDEO_DISPLAY_KEY "zoom_factor" which was the 
wrong choice, mv->screen would have been the better choice. But due to the 
existance of a) - d), that only a) naturally represents the true asyncronous 
switching state and that d) has been named fs_active, which is true only for 
the syncronous, I have to be intrusive to gm_main_window_update_video. 

> convince myself it does the right things.
>
Well, in a multithreaded environment, it is difficult to write down all 
eventualities, see points 1) -7) above.

> In particular, what prevents us from turning :
>    void
>    gm_mw_init_fullscreen_video_window (GtkWidget *main_window)
>    {
>      <init code>
>    }
> into:
>    static gboolean
>    gm_mw_init_fullscreen_video_window_idle (gpointer data)
>    {
>      <turn data into main_window>
>      <init code (same as before)>
>    }
>    void
>    gm_mw_init_fullscreen_video_window (GtkWidget *main_window)
>    {
>      /* this hack is required for the win32 port */
>      g_idle_add (gm_mw_init_fullscreen_video_window, main_window);
>    }
> and the same trick for gm_mw_destroy_fullscreen_video_window? (Apart
Nothing really. I had just a single toggling routine and the gm_mw_init / 
gm_mw_destroy pair were sort of gate keeping

> from the fact that a mutex would certainly be needed to protect the
> access to mw->screen ?)
Hmmm, I hate mutexes, spinlocks and alike. So I always ask whether one really 
needs one. In the scenario defined by 1) - 7) a simple variable a) or b) is 
sufficient, I think, because the drawing threads only read from it and the 
switching routines which also write to it are queued and can never interrupt 
themselves.

Now to the SDL.  In Windows there is quite a bit of include file and linker 
magic going on. SDL provides its own WinMain function. During compilation 
main in Ekiga's main.cpp is redefinded to SDL_main. SDL's WinMain 
(SDL-1.2.9/src/main/win32/SDL_win32_main.c) calls console_main(argc, argv) 
which calls SDL_main(argc, argv), i.e. Ekigas. The linker uses the WinMain in 
libSDLmain.a (I checked it) and not Ekigas WinMain. In SDL's WinMain command 
line parsing and redirection of stdout/stderr is done.

> I also have a question about the SDL code ; it isn't precisely about the
> discussed patch, but it fell on me while studying to understand it :
> wouldn't it be possible to do the SDL_Init (SDL_INIT_VIDEO) once at
> startup, and SDL_Quit () once at shutdown ? 
I have played with that some time ago. In priciple its possible. And in 
SDL_win32_main.c there is a call to SDL_Init(SDL_INIT_NOPARACHUTE), but
calling SDL_Init resp. SDL_InitSubsystem and SDL_SetVideoMode have to be 
executed by the same thread in Win32.

> It doesn't seem logical to 
> load&init then clean&unload SDL each and every time the user toggles
> fullscreen.
For Linux, why not, for Windows we could do it through GLib.
>
> Snark
>
> PS: it's unrelated, but why aren't gm_mw_init_fullscreen_video_window
> and gm_mw_destroy_fullscreen_video_window static ?

So how shall I proceed ? I will use mv->screen as a guide post because that 
avoids changes to other files than main.cpp. Intrusion into 
gm_main_window_update_video seems unavoidable, at present it is not ment for 
asynchronous processing. On the other side I cannot see any reason why a 
routine which can handle things asynchronouly cannot be used for synchronous 
executeion. Variable display_type becomes actually a request_display_type. 
Variable fs_active should be set according to mv->screen. And the switching 
should depend on request_display_type. What shall I do to VIDEO_DISPLAY_KEY 
"zoom_factor". It can only be set to request_display_type if no other 
routines rely on fullscreen being actually active. And all this to Ekiga's 
holy grail ?
I could prepare a separate patch to clear up the remaining Win32-SDL issues, 
i.e.  exclude WinMain, make main C-style, enable argv, argc where they have 
been disabled for Windows. A third patch could just set a Windows-global 
mutex to prevent several instances of Ekiga. And a 4th patch could add 
command line parsing for non-SDL versions of Win32 ekiga so that they too can 
enable debug output.
Regards
Michael