after much confusion, it is time for a deep breath. first, let me
specify my goal precisely:
1) the first goal is to be able to work on a local buffer, which has a
target-independent format. this can be a ggi_color* or a ggi_pixel*
buffer, for example. the requirements for this buffer is that it
should have a target-independent format, and should be modifiable
(ideally) without any calls to a ggi function to avoid the overhead.
2) then i should be able to map this buffer into a ggiPutBox-ready
buffer. the requirements for this step is that the mapping should
be as fast as possible.
reason for these requirements: to map a locally modifiable bitmap as
fast as possible, without worrying about target issues, without having
to call ggiPutPixel for every pixel.
now let us see what can i do (thanks for your suggestions)
a) use ggiPackColors on a ggi_color* buffer. this satisfies requisite
(1) above but doesn't seem to satisfy requisite (2). i looked at
the sources and it seems impossible for any compiler to optimize
the map color call (it's a pointer call).
b) use ggiCrossBlit together with a memory target. this replaces the
call to ggiPutBox. this seems to be as fast as ggiPutBox provided
the memory target has the same depth as the actual target, so it
satisfies (2). since i can ggiPutPixel to the memory target, it
*almost* satisfies (1), because i still have to call a ggi function
for every pixel on the memory buffer.
for my purposes, it actually seems that both options are equivalent if
i cache the void* buffers for ggiPutBox. with option (a), there will
be one call for mapping colors per pixel. with option (b), there will
be one call for putting pixels per pixel. tough decision, and i
actually have no idea which one will be faster, although i guess it
will be (a), because the function calls are within the same library,
but that is a wild guess.
living and learning.
--
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
