| Re: [AD] XOR drawing under X11 (and what is _xwin_in_gfx_call) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Mon, 2004-11-29 at 03:25 -0800, Chris wrote:
> Elias Pschernig wrote:
> > Hm. I think it can't work. Just think of cases like this:
> >
> > thread 1:
> > XLOCK();
> > bmp->vtable = &orig_vtable;
> > *** context switch ***
> >
> > thread 2:
> > draw(bmp); /* will use the wrong vtable method */
>
> In that case, the second thread's draw operation will block on XLOCK
> until the first thread completes drawing and XUNLOCKs.
>
No. Since you overwrote it with a non-blocking version, just one line
before the switch. Or even if we always require locking in any vtable
functions, it still would block now in the wrong method, the one which
does no updating.
> > Maybe we could copy the bitmap, like this:
> >
> > void _some_draw_function()
> > {
> > BITMAP temp = *bmp;
> > for (i = h; i < bmp->h; i++) temp.line[i] = bmp->line[i];
>
> Right there you'd be overwriting memory. Don't forget the line[]
> pointers reference memory that extend out past the structure.
>
Yes, need to allocate the memory, making this even more time consuming.
> > For Allegro 4.3.x, I think, we could require all access to a bitmap to
> > be locked. That is, a function like putpixel would look like this:
> >
> > acquire_bitmap ();
> > vtable->putpixel
> > release_bitmap ()
> >
> > instead of right now:
> >
> > vtable->putpixel /* locking is done by the vtable method */
>
> I thought about this, and here's the thing. Granted putpixel is a poor
> example here, but if a vtable entry can potentially be hardware
> accelerated, you need the surface unlocked to do it. Forcing a lock only
> to have it unlocked by the vtable entry before the operation even takes
> place is a bit wasteful, don't you think?
>
Hm, good point. I don't know much about this, but I guess e.g. the
DirectX driver behaves like that? If it does, then yes, it would be bad
- guess need to do some more thinking for 4.3.x.
Anyway, currently, vtable entries never know if they are called on a
locked bitmap or not without checking - that's why you can't change a
vtable entry to point to a version which assumes it is called when
already locked, or even change any vtable entry, since it will be called
before possibly blocking on a lock.
So, looks like there's no alternative to always locking, and keeping
in_gfx_call, for now, right?