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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2004-11-26 at 15:38 -0800, Chris wrote:
> >>
> >>Right (and even then, only if it's drawing to the memory bitmap itself, 
> >>not the display). Although if that ever happened, then the display would 
> >>never be updated with the second drawing operation, unless it happened 
> >>to be inside the same area as the first (which would cause its own 
> >>problems).
> > 
> > Yes. So very odd. Would need to find Michail Bukin or Geroge Foot and
> > ask them what this is about :)
> 
> Weren't we going to drop the SIGALRM version anyway? When do we plan on 
> doing that?
> 

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.

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 see three possibilities:

1. Just put locks around the drawing functions. This shouldn't have a
dramatic impact I think - would need testing of course. In this case,
every change to in_gfx_call would be inside the lock, so only one
function at a time could claim in_gfx_call, and then when calling others
they rightly assume they are being called by another gfx function.

2. Remove in_gfx_call, and create *_private variants, like done in other
parts of the X11 code. The _private functions then would be called from
the other functions. The _private functions would do neither locking nor
updating, so this would just be the behavior intended originally by the
undocumented in_gfx_call.

3. Leave it as is. It will work as long as only one thread calls those
functions. The mouse drawing only calls blit() and draw_sprite(), and I
think those won't call other gfx functions from inside them - so
in_gfx_call isn't used with them.

I think, the cleanest solution is 2. It clutters everything with lots of
ugly _private variants, but what isn't all done in the name of
optimization. 3. should only be done if we give up on making allegro's
gfx functions reentrant. 2. may be the best thing to do if it is as fast
as 3.

- Remove