Re: [AD] spin lock in xvtable.c

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

[Sorry for the very long delay...]

> When the X11 driver is loaded, it copies all the vtable functions to
> _xwin_vtable, then loads all the xwin functions into the vtable passed
> as a paramter. Then, when a function like putpixel is called, the
> xwin_putpixel is instead called which in turn calls the
> _xwin_vtable.putpixel which is the *original* putpixel in vtable passed
> to _xwin_replace_vtable.

That's right.

> Is the only point of this to add the line _xwin_update_video_bitmap?

Basically, yes. The advantage of this method is the following: the regular
drawing primitives don't understand the concept of "drawing boxes", that is
there is no way for them to tell the underlying gfx driver that they have
only touched a particular box in the bitmap. They only understand the
concept of scanlines, that is, once one pixel is touched, all other pixels
with the same y coordinate are updated. This approach is suited to
fullscreen gfx drivers, for which the VRAM is directly accessed on a per
scanline basis, but not for all windowed drivers, which are traditionally
double-buffered. Especially for the X11 driver which is intrinsically slow.
So, by short-circuiting the drawing primitives, the driver is able to limit
as much as possible the amount of pixels it sends for each frame to the X
server.

> Im not sure what this function does, but it seems that its the only
> addition to the X11 functions.

It is basically equivalent to _xwin_update_screen, which is the function
that copies the backbuffer to the frontbuffer for the double-buffered X11
driver.

> In that case, I could see how if _xwin_in_gfx_call being set to 1 would
> enable _xwin_vtable.func to be called twice, once right after
> _xwin_in_gfx_call = 1;
> _xwin_vtable.func();
>
> and once in intial if statement such that both calls will be placed
> before _xwin_update_video_bitmap is called thus saving time and energy.

_xwin_vtable.func is never called twice for a fixed func method: either
_xwin_in_gfx_call is set to 1 and it is called within the if block *and* the
function immediately returns, or _xwin_in_gfx_call is set to 0 and it is
called in the main codepath only.

> What I dont get is, how could two functions be running at the same time?

I'm not really sure what you mean by this sentence. Certainly, when a
function calls another function, the first function can be seen as still
"alive", although it is not really running any longer. Things are even more
interesting when the second function is the same as the first one, but that
works.

> It is known that allegro cant be multithreaded, so doesnt that enforce
> the function to complete without having to worry about placing another
> call in between _xwin_in_gfx_call=1 and _xwin_in_gfx_call=0?

Note that, as I said before, _xwin_vtable.func is never called twice for a
given func. The codepaths are mutually exclusive.

> Also, if the the function does get called a second time but the first
> function finished the _xwin_vtable.func function right before the second
> function starts the _xwin_vtable.func function, then
> _xwin_update_video_bitmap would be called once after the first function
> finishes, but would need to be called again after the second function
> finishes.

As you said, drawing primitives can't be used simultaneously by different
threads so this can't happen (more precisely, Allegro doesn't support it so
we don't care).

--
Eric Botcazou