In reply to "Brian S. Julin" <[EMAIL PROTECTED]>
>
>On Tue, 26 Dec 2000 [EMAIL PROTECTED] wrote:
>> well, sort of. an array of ggi_pixels* isn't (always) suitable for
>> ggiPutBox.
>
>You pretty much shouldn't be using arrays of ggi_pixel. ggi_pixel is
>nothing but a data type that is big enough to hold all currently known
>pixel values, and is only really meant to be used when you are actually
>working with single pixels.
"you shouldn't" should be a programmer decision. your reasons tell me
nothing about why i shouldn't. there's nothing essentially wrong in
building an array of pixels of the current visual. as we already saw,
it is more efficient, both memorywise and speedwise, than the
equivalent array of colors.
>> whenever you call ggiPackColors, you are indirectly doing this:
>>
>> for(i) (ggi_pixel_buffer[i]=ggiMapColor(ggi_color_buffer[i])
>> for(i) (ggi_void_buffer[i]=format_dependent_mapping(ggi_pixel_buffer[i]))
>
>Take a look at degas/lib/libggi/default/color/pack.c. This is not the
>way it works (would be inefficient to alloc the array of ggi_pixels).
as i noted in the original message, the intermediate buffer is
actually not created. it doesn't matter, because we have
*dest++ = (uint16) LIBGGIMapColor(vis, cols);
and LIBGGIMapColor is, from internal.h
vis->opcolor->mapcolor(vis,col)
this is a pointer call, and i doubt it will be inlined by any
compiler for a program using generic targets. as such, the line from
pack.c is overwhelmingly slowed down by the call to LIBGGIMapColor.
were cols a pixel array, packing would be oh much much faster.
>The values from the call to ggiMapColor are cast into the right size for
>the buffer one by one.
which is fast. but it doesn't matter because calls to ggiMapColor are
slow.
>The code I offered accounts for this. The 8bpp grayscale values and the
>fgcolor/bgcolor are used as an index into an array of pre-packed pixel
>values.
yep.
>"Generic" and "efficient" are two goals we have to balance against each
>other.
not always. in particular, not in this case.
>We've already shown you a relatively efficient and generic solution
>(using a memvisual and cross-blitting.) If you want more efficiency,
>you have to sacrifice generic operation.
why? why can you have
*dest++ = (uint16) LIBGGIMapColor(vis, cols);
but not
*dest++ = cols;
?? why is it allowed to abstract the target from the color point of
view but not from the pixel point of view? if "color" is the right
thing, then why can i ggiPutPixel ???? the very same argument applies
here.
if you argue in favor of ggiPackColors, you should also argue in favor
of ggiPutColor (which doesn't exist). for if you can't have "an array
of pixels," then by extension you shouldn't have a "pixel" but a
"color." if you allow "one pixel", you should allow "many." that's
clear to me. just clear your mind from "accepted practice" and i think
the reasoning should be clear enough. we shouldn't think as "how it
is," but rather as "how it should be."
but ggiPutColor doesn't exist, so i guess you will argue for
ggiPutPixel. and the reason is that you have "one pixel" and you want
to put it. how do you get the pixel? aside from ggiGetPixel, with
ggiMapColor. so you are effectively saying "for one pixel, you do
ggiMapColor yourself. and we abstract the target specifics for you
with ggiPutPixel. but for many, we don't let you." it is a
contradiction.
>LibGGI allows you to drill down the detail on the target to a level
>appropriate to how much you want to tweak for efficiency. Mainly by
>generic we are talking about generic across different display systems
>(X11, fb, etc.). It isn't there to make 32bpp and 1bpp visuals look
>identical, unless you are writing one-shot quicky code. You're
>expected to care about and deal with the buffer depth. Almost all
>graphics programmers do.
yes. but in some cases, unecessarily.
>> ggiPackPixels, something which i am ever more convinced should be in
>> the api (since it's already there hidden)
>[...]
>> b: ah, it slowly transforms your larger ggi_color array into a ggi_pixel
>> array by mapping every single pixel, and then it efficiently
>> transforms the ggi_pixels array into a ggiPutBox ready array.
>
>No, it isn't, and no it doesn't. I don't know if it ever did, but you
>may want to check that you have a recent snapshot of the codebase.
there is in some part of the original message the phrase "modulo
intermediate buffer." the whole slowdown (and a big one at that) is
caused by ggiMapColors. the "slowly transforms" means "calls
ggiMapColor for every pixel." think of it as a pipe. it *is* already
implemented. it is clear to see when you rewrite
*dest++ = (uint16) LIBGGIMapColor(vis, cols);
as
pixel = (uint16) LIBGGIMapColor(vis, cols);
*dest++ = pixel;
both lines together are ggiPackColors. the second one is
ggiPackPixels. it is overwhelmingly trivial, but what it does, and
what makes it great, is to hide the target specifics. and that's why
you have ggiPackColors in the first place. otherwise you could as well
MapColor and proceed with the 'switch' statement.
so if you argue against ggiPackPixels with a 'switch' code, bound to
fail at some point in the future, i will argue for the removal of
ggiPackColors on the exact same ground. down with ggiPackColors!
>Honestly, as long as you don't set GT_SUB_PACKED_GETPUT, the code we
>are talking about is a < 50 line macro/inline, and there is a lot of
>room for optimizing it to any particular application, so it is better
>off as an application-specific routine, IMO. Not having it there
>will force app developers to think about optimizing. :-)
and when they think, they realize that everything is already
implemented but inaccessible. and the exact same argument could be
applied to ggiPackColors. but i rest my case, since it looks like i
wasn't able to convince anybody ;) my position remains the same:
either ggiPackPixels and ggiPackColors together, or none.
i'm done with this thread. and in december 31, turn of the millenium,
i turn 30, as if this would matter to anyone. happy new year!
--
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
