On Wednesday 29 March 2006 12:37, Julien PUYDT wrote: > Michael Rickmann a écrit : > > don't bother. I make a new Win32 SDL patch. Just got an idea. > > Thanks :-) > > Snark > _______________________________________________ > Gnomemeeting-devel-list mailing list > Gnomemeeting-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list Hello Julien, here it is. I tried to include your suggestions and commented the changes a bit, so that one sees what meaning the changes have. I repeat from my earlier Mail > 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 This time I have chosen mv-screen as the guide post. The patch works very well without a mutex around mv-screen. The only shortcoming which could be fixed with a mutex is: In the current version, during switching interval, several request of the same kind accumulate in the Glib main loop. Naturally only the first reaches the SDL layer. I think we do not need that mutex either. I had to stick with the SDL_QuitSubSystem, freeing the surface was not sufficient to destroy the Windows window. As to the remaining Win32 SDL issues / wishes (command line parsing, start only once), there are two possibilities. 1) Following the SDL include file & linker magic would need a C style main function, is rather unflexible and the code would look a bit ugly. 2) When writing an own WinMain function I could use Glib's command line parsing, load ddraw.exe and SDL.dll set my Windows global mutex, and Ekiga's main would remain fairly untouched. But we would possibly loose compatibility with future versions of SDL. Question to everybody: How shall I proceed ? If you vote for 2), do we need to redirect stdout and stderr ? Regards Michael
Attachment:
ekiga-win32-patch-1.tar.gz
Description: application/tgz