Brad Beveridge writes: > The biggest surprise for me was seeing that fairly trivial functions > were consing a lot of data. From memory the functions that surprised > me were: > PACK-COLOR > FP > R > G > B > A > > All functions that should really be non-consing & very quick, and > probably inline too. I think that R, G, B, A functions are slow due > to the way that Lispbuilder stores color as a vector, rather than a > (simple-array (unsigned-byte 8)), though it maybe should even be an > (unsigned-byte 32).
The problem is that the SDL API is itself very inconsistent in its handling of color. Some functions take an integer color, some functions take separate R, G, B, A char values. Some functions return an integer color. Some functions expect pointers to R, G, B, A chars and return color that way. And then SDL-ttf expects color as a struct. For example: The SDL_gfx APIs expect color to be an integer, so the RGBA values are packed each call. But the SDL APIs (e.g. SDL_FillSurface), require that the color be first mapped to a surface. And SDL_MapRGB takes separate R/G/B/A char values. So what is good for SDL is bad for SDL_gfx. It may be more efficient to have the COLOR object contain the color RGBA representation as both a vector (or array) and an integer. SDL reads the vector (or array) and sdl_gfx reads the integer. - Luke _______________________________________________ application-builder mailing list [email protected] http://www.lispniks.com/mailman/listinfo/application-builder
