Re: [AD] Allegro 4.2 planning

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-10-18 at 22:55 +0200, Elias Pschernig wrote:

> 
> I'll look into this. It's simpler than trying to change the complete
> locking mechanism.. I have a modified version of Allegro here which
> creates two displays, but when running, it simply locks up :P Probably
> would just need some debugging. 

Atually, I could fix it at once when looking at it again. I just had to
change the x_flush_buffers call - it may only be called with the input
display of course, from the background/events thread. And I needed to
add an XFlush(gfx display) call to the x_redraw_window function - the
gfx subsystem never can call a function which the event subsystem can
also use.

I'm right now running an Allegro 4.1.17 with full XIM support :) Even
combination keys work perfectly.

Still need to test performance.. maybe it got worse by removing X
locking. And, there's some places which need extra synchronization now,
since x_lock and x_unlock simply are gone (may need some pthreads
locking now.. e.g. for mouse drawing, or special things like shutting
down). There are 2 independent connections to the X server, one for
input, one for output. The same connection may not be used concurrently
from two threads. (So I still get X Asyn replies right now, but only in
special situation, actually just on shut down).

I'll clean all the printfs I put in the code, and post a patch against
CVS, probably on the weekend.. will need some time until this is mature
in any case - but I'd prefer it now for 4.2 instead of the xkeymap
stuff. Not sure how much time I will find to hack on it though.

And it will also require some merging with the new_api_branch - since
Peter also wrote a new keyboard API there (much simpler than mine). But
if there's no performance problems, my version currently is superior,
even to SDL :)

-- 
Elias Pschernig