[ 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