[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Angelo Mottola <a.mottola@xxxxxxxxxx> writes:
> This isn't easy. X version has a different updating approach than Windows
> one; just in X there are two different color color conversion/window updating
X specific color conversion can be added to X version only.
> set of routines, one fast (using direct memory writes) and the other slow
> (using Xlib when the first method isn't available). Also, X updates the
> window during the line switches, and it just redraws the lines actually
> changed.
X version can also update rectangular area by calling color conversion
routines from X specific vtable functions linked from screen->vtable.
These vtable functions are special to X version, because they call
window update functions after calling normal vtable function. If
color conversion routines will be used by other platforms, then
wrapper vtable functions can be used by other platforms too.
> rectangle to update. This is exactly how current X and Be color conversion
> routines work; something like:
>
> void update_bpp_to_bpp(void *source, void *dest, int x, int y, int w, int h);
I think it should take pointers to functions which take line number
and return pointer to the beginning of that line. Then these
functions may call bank switching routines if necessary (it might be
necessary for DGA driver).
/* From one Allegro format to another Allegro format. */
void update_bpp_to_bpp (unsigned char *(*get_src_line) (int line),
unsigned char *(*get_dst_line) (int line),
int x, int y, int w, int h);
/* From Allegro format to some truecolor format. */
void update_bpp_to_truecolor (...);
/* From Allegro format to some paletted format. */
void update_bpp_to_palette (...);
Actually, for X version, source will always be memory bitmap in
Allegro format, so we can pass (unsigned char **), or something
similar, but not current screen BITMAP, because it can be changed
(see setup/setup.c, for example).
>
> We could also make the source and dest parameters to be set at driver
> startup, so that the update function needs only 4 parameters (thus less
> push/pop calls).
It will not save much, IMHO, so we can pass all necessary information
in arguments.
> can you convert the routines in update.s to support the
> given parameters (and not to update the whole screen)? Your asm routines
> could then be used also in X and Be, with a great benefit.
X driver support more destination formats than BeOS and Windows
drivers. It uses up to 4 lookup tables to make necessary conversion
from Allegro format to destination format, thus it avoids using shifts
when destination is in truecolor format and it avoids searches for
best color if destination is in some other format. These lookup
tables are prepared in initialization and in set_palette (for 8bpp
screen).
>
> Michael, what do you think of all this? You coded the original X conversion
> routines and window updating, so it would be cool to hear your point of view.
I agree with this idea, but it will be necessary to supply generic C
versions for any ASM routines, or it can not be used in X (some
conditionals will be necessary to call generic functions instead of
ASM ones).
--
Michael Bukin