[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Friday 06 August 2004 09:50, Chris wrote:
> This patch implements XLOCK for acquire_screen, as well as the previous
> primitives patch. Since X is allowed to buffer calls and send them to
> the server en-mass, it seemed like a good idea to try and hold a lock
> while the screen is being drawn on.. since to me, it seems Allegro's
> putpixel test is XLOCK-limited, not speed-limited. And indeed, after
> implementation some of Allegro's primitives tests (circlefill,
> ellipsefill, etc, which rely on putpixel) showed substantial
> improvement.. more than double performance (circlefill went from ~400
> per second to ~1000 per second). I wouldn't doubt that if X buffers the
> PutImage calls, we could see a marked improvement there, too.
I just tried your patch. Works a treat, and things are really being drawn
notably faster. Good work!
As far as I'm concerned, it can be applied. I'll just leave it for a few
others to test first though. I'll be away from the 8th of August to the
17th though (so someone else can apply it in the mean time).
> However, if the sound was put into its own
> thread (or perhaps even the timer thread), that issue would be resolved.
I think having a dedicated sound thread makes sense. I'm not sure what the
plans from the original Allegro 5 draft were where threads were
concerned...?
That said, Allegro's threading needs to be looked at closely anyway (see
the `make library internally thread-safe' item on the todo list).
> However, after having to reboot
> my computer due to it, I don't think I'm going to try persuing this
> again anytime soon.
Hmm... sounds bad. But we can look into that again at a later time I
guess...
Evert