vsync simulation [was: Re: [AD] XIM patch for Allegro 4.1.x]

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2004-10-27 at 11:15 +1000, Peter Wang wrote:
> >If vsync runs from the background thread, wouldn't it still need access
> >to the timer counter?
> >  
> >
> 
> It wouldn't be running from the background thread.  The vsync-emulation 
> would work as it does now, but retrace_count would be incremented from 
> the bgman thread instead of the timer thread.  That should work, but it 
> might cause other problems that I haven't thought about.  To be safe 
> (and for a nicer fit with the existing code), we can just introduce a 
> different counter that is incremented from the bgman thread and leave 
> retrace_count to be incremented by the timer thread.
> 

I tried expal with current CVS, and the same happens - it simply
deadlocks - so this wasn't caused at all by using a pthreads mutex.
Which actually is good, since this deadlock, along with the DGA2 mode
detection async reply (which also is done when not using DGA2, but just
by clicking around in the gfx selection), might just be the cases where
I very rarly got deadlocks/async replies with Allegro in the past - and
now maybe everything is fixed :)

For now, I applied the attached patch which makes the function just call
XSync (which somehow can have a similiar effect), and a comment telling
how it can be fixed. I also put it to the todo.txt, and made expal
display a mouse cursor.

-- 
Elias Pschernig

Index: todo.txt
===================================================================
RCS file: /cvsroot/alleg/allegro/todo.txt,v
retrieving revision 1.181
diff -u -p -r1.181 todo.txt
--- todo.txt	17 Oct 2004 09:01:29 -0000	1.181
+++ todo.txt	30 Oct 2004 22:37:33 -0000
@@ -42,6 +42,7 @@ X11 todos:
   driver and the Mac OSX driver. Currently, we expect application users to
   fiddle with xkeymap.
 - Investigate problems with the SIGALRM version
+- Look for a better solution to simulate vsync.
 
 Unix todos:
 ---------------------------------------------------------------------------
Index: src/x/xwin.c
===================================================================
RCS file: /cvsroot/alleg/allegro/src/x/xwin.c,v
retrieving revision 1.73
diff -u -p -r1.73 xwin.c
--- src/x/xwin.c	25 Sep 2004 08:33:31 -0000	1.73
+++ src/x/xwin.c	30 Oct 2004 22:37:36 -0000
@@ -2166,12 +2166,15 @@ void _xwin_flush_buffers(void)
  */
 void _xwin_vsync(void)
 {
-   if (_timer_installed) {
-      int prev = retrace_count;
-
-      do {
-      } while (retrace_count == prev);
-   }
+   /* This does not wait for the VBI - but it waits until X11 has synchronized,
+    * i.e. until actual changes are visible. So it has a similar effect. A
+    * better solution might be waiting a specific time to simulate a VBI (but
+    * the X11 mutex might be locked by the timer thread), or using the XSync
+    * extension.
+    */
+   XLOCK();
+   XSync(_xwin.display, False);
+   XUNLOCK();
 }