[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> That's the idea, have only a piece of code which performs color
> conversion, having only to code some OS dependant functions. Right now
> there are two versions, the X one (Michael's?) and mine in
> win/update.s. So why don't mix them in some OS independant color
> conversion functions and use them in all windowed drivers or even in
> blit functions?
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
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.
I've examined a little the DX windowed driver (your code), and it seems to me
it updates the window during the bitmap release only, updating the whole
screen, and not just the modified lines (correct me if I'm wrong! I've not
examined it very well)
BeOS windowed driver currently works similar to the X one, except it has one
updating method only (direct memory writes).
What do you suggest?
A possible solution would be to code a set of routines that take two pointers
of the source and dest bitmaps data, and the x, y, width and height of the
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);
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).
This set of routines could then be used by all the windowed drivers that need
them. But the problem is that you have to change the current way the DX
windowed driver work; 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.
Of course we'd also need to discuss the paletted conversion problem; I've
seen Windows driver doesn't support conversion from true/hicolor to 8bit,
while X does.
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.
--
Angelo Mottola
a.mottola@xxxxxxxxxx
ICQ UIN 66972680