[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
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).
While X is locked durring drawing operations, it allows the X server to
better buffer the drawing operations, resulting in a nice speedup.
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.
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. :)
= Kitty Cat