Re: [AD] retrace_proc is wrong

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Sat, 2004-07-31 at 13:13 +1000, Peter Wang wrote:
> retrace_proc works just like a "timer" callback, so could be run from a 
> background thread.  This means things like altering the palette should 
> not be allowed, meaning the documentation is utterly out of date:
> 
> extern void (*retrace_proc)();
>      [snip]
>      The only use I can see for
>      this function is for doing palette manipulations, because triple
>      buffering can be done with the request_scroll() function, and the
>      retrace_count variable can be used for timing your code. If you
>      want to alter the palette in the retrace_proc you should use the
>      inline _set_color() function rather than the regular set_color() or
>      set_palette(), and you shouldn't try to alter more than two or
>      three palette entries in a single retrace.
> 
> I suggest we deprecate retrace_proc in the unstable branch.  Given its 
> uselessness, I would like to see it removed.  It could be retained as a 
> DOS-only feature, but deprecated.
> 

I agree, we should deprecate it. I've seen it used quite oten in various
Allegro programs, but only because people are too lazy to create a
proper timer (see for example the uses in the Allegro examples itself),
and never for its original purpose to sync to the monitor retrace.

> ex3buf should also be fixed.
> 

Didn't think about that when changing ex3buf. Maybe we can remove
ex3buf? exdbuf and ex3buf seem to be superceeded by exflip anyway. And
it's bad practice to hardcode a fixed update method in any way. Better
provide a good example how to autodetect the best update method.. in
case we add the new set_display_mode from that other thread, we should
change exflip to demonstrate that instead.

Maybe it's time we add a simple: al_create_lock / al_acquire_lock /
al_release_lock API. I'm not sure, but I think there is one proposal in
the A5 docs.

(And together with my new input module which uses a separate X display
for input, this completely would fix all problems in the X11 port,
threaded and signalled.)

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/