I think maybe we're just seeing the evils of early optimisation. Correct me if I'm wrong Luke, but you basically abstracted the colour into lisp data to make it easier to work with, but there's nothing stopping you from identifying bottle-necks and using the cffi-sdl layer, using raw C structs?
I'm not sure we can have it both ways: easy to use lisp structures that map directly to the underlying representation. Justin On 15/10/2007, Luke J Crook <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ application-builder mailing list [email protected] http://www.lispniks.com/mailman/listinfo/application-builder
