Re: [AD] X11 locking

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Thu, 2004-09-02 at 18:45 -0700, Chris wrote:
> Elias Pschernig wrote:
> > I guess I could just read the SF archives, but I don't like the web-
> > interface much, so I'm just asking here :) Why do we need the _xwin_lock
> > and _xwin_unlock functions?
> 
> I created _xwin_lock and _xwin_unlock to map to 
> acquire_bitmap/release_bitmap, when the bitmap being called is a video 
> bitmap. This allows multiple locks so that calling XLOCK twice in the 
> same thread doesn't freeze the program (say if you call XLOCK when you 
> acquire the BITMAP, then XLOCK is called again when you go to draw it to 
> the X display.. the second lock will wait for the first to release which 
> would never happen because the second lock is blocking the program). 

I think I see. Is support for acquire_bitmap new in the X11 port? Or why
would it work before?

> While X is locked durring drawing operations, it allows the X server to 
> better buffer the drawing operations, resulting in a nice speedup.
> 

Makes sense. XLOCK already did that though, right?

> It does however seem to have issues when the program doesn't adequately 
> rest.. if a tight loop unlocks then quickly locks again, another thread 
> (the input bg thread, for instance) doesn't seem to notice the unlock. 
> That's my asessment, anyway.. it may be wrong.
> 

Hm, don't know. I'll try to find out what part of my freezing program
causes the lock-up - it doesn't use any video bitmaps or acquire_bitmap
calls.. but it draws to the screen from different threads. Since this
program worked always including up to 4.1.15, it would be a shame if I
have to fix it now :P I'm wondering if maybe the locking used in
_xwin_lock is too weak, and we need to do it with a real (pthreads)
lock. And maybe dis-allow locked X11 video bitmaps in the signals
version. I don't really have an idea though what I'm talking about..
I'll do some more testing now.

> > Oh, and while going therough some patches, is the change in xwin.c below
> > correct?
> > 
> [snip]
>  >
> > To me it seems, it now causes a call to (*_xwin_window_redrawer) even if
> > it should have been clipped away. (I don't know what
> > _xwin.screen_to_buffer does and why the change was made though, so it
> > may be right. It just looked strange..)
> 
> _xwin.screen_to_buffer is a helper function (pointer) to copy the screen 
> data to an internal buffer for when the screen depth and X display depth 
> don't match. (*_xwin_window_redrawer) does it's own clipping to the 
> visible screen area, while the clipping I moved into the conditional 
> only clips to the virtual screen size. The initial clipping only needs 
> to be done for screen_to_buffer so it doesn't attempt to overrun the 
> memory buffers, while the clipping that _xwin_window_redrawer does makes 
> sure that it only redraws the physical screen. IMO there's no reason to 
> clip to the virtual screen size then to the physical screen size when 
> not using screen_to_buffer.. there's no justification for all that extra 
> branching when the second clip is sufficient.
> 
> I hope that answers your questions. :)
> 

Yes, makes sense - the clipping was unnecessary before in the case when
_xwin.screen_to_buffer was 0. Just was too lazy to look up what the
called functions do myself :)

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/