In reply to Marcus Sundberg <[EMAIL PROTECTED]>
>
>> ggi provides a ggiPackColors routine, which internally has to map the
>> colors of the array. so why does not ggi provides a ggiPackPixels
>> routine? it seems it would be much more efficient, and easier/shorter
>> to implement than ggiPackColors. any particular design reason?
>
>I don't get you. You can pack a ggi_color into a pixel, and you can
>unpack a pixel into a ggi_color. Functions for both already exist
>(ggiPackColors and ggiUnpackPixels respectively). What would the
>ggiPackPixels() function do?
make me faster without having to make me worry about the specifics of
the target in use. in my application i have to save a bitmap as a
ggi_color buffer, pack it once, render a few times with ggiPutBox. if
i need to change the bitmap colors, i change the ggi_color buffer and
repack it. this packing involves mapping colors internally in ggi. if
i had the possibility of passing from a ggi_pixel* buffer to a packed
one things would be a lot faster. but right now i cannot pass from a
ggi_pixel* buffer to a ggiPutBox buffer without passing through a
ggi_color buffer in between.
check out the packing functions in default/color/pack.c. they all map
colors, which is a redundancy if i already have the pixels. that's why
i don't understand why there's no ggiPackPixels. it's faster, simpler
to implement, and a ggi_pixel* buffer is, for the end user, as
format-(target,mode)-independent as a ggi_color buffer after the
colors are mapped. it would be a faster option if implemented. and one
of the points i'm making is that ggiPackColors and ggiPackPixels are
somewhat equivalent to the end user and for the ggi library, but
ggiPackPixels would be a better choice performancewise. i consider
that having one but not other is in either case strange. either you
have both or you have none.
--
Cesar Augusto Rorato Crusius __o __o __o __o __o
Stanford University _`\<, _`\<, _`\<, _`\<, _`\<,
e-mail:[EMAIL PROTECTED] (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_)
www.stanford.edu/~crusius
o _ _ _
__o __o __o __o /\_ _ \\o (_)\__/o (_)
_`\<, _`\<, _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/
(_)/(_) (_)/(_) (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
He who sacrifices functionality for ease of use
Loses both and deserves neither
