Re: [AD] XOR drawing under X11 (and what is _xwin_in_gfx_call)

[Chris <chris.kcat@xxxxxxxxxx>]

Elias Pschernig wrote:
> Ok, while looking for info on the general screen-clipping race
> condition, I found this:
>
>
>  From: Eric Botcazou <ebotcazou@xxxxxxxxxx...> 
> Re: spin lock in xvtable.c   
>  2003-08-14 22:35
>  > In all the functions in xvtable.c, the first line of code is
>  > essentially a semaphore to allow for reentrant calls( i guess to make it
>  > multithreaded which it cant do anyway ).
>  
>  This is indeed a semaphore, but not really for reentrant calls. It is
>  intended to detect when low-level drawing functions are called by high-level
>  drawing functions (for example, hline() by triangle()), thus allowing to
>  bypass the clipping and updating codes for the lower-level functions in this
>  situation, which results in a huge speed-up for the X11 driver.

Ohh, I see now. Okay. But, instead of that, wouldn't it be better to 
replace the bitmap's vtable with the original memory one, call the 
memory bitmap function (which would in turn call other memory funcs 
directly as needed), then restore the vtable with the video bitmap 
vtable before updating the display? It would be more efficient (since it 
wouldn't have to go through two vtables to do the same thing), make more 
sense to others looking at it, and it would keep the code from looking ugly.

> So, it is just for the case where a function is called by another. I
> guess, e.g. rectfill calls hline, and therefore the called hline doesn't
> need to care about any updating. (Why did who added this not document
> it?)
>
> Of course, this also means, that it doesn't work at all in a
> multi-threaded environment.

I think my solution would handle this perfectly. Basically what it'd do is:

void _some_draw_function()
{
   XLOCK();
   bmp->vtable = &orig_vtable;
   orig_vtable.draw_func(bmp, ...);
   bmp->vtable = &video_vtable;
   update_display();
   XUNLOCK();
}

This way, another thread wouldn't be able to even attempt to draw while 
the vtable is switched and the display is updating. Granted this would 
mean holding the lock for a touch longer per drawing operation, but 
multiple drawing operations should all be enclosed in a single 
acquire/release_bitmap pair anyway.