In reply to "Brian S. Julin" <[EMAIL PROTECTED]>
>
>On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote:
>> ggi provides a ggiPackColors routine, which internally has to map the
>> colors of the array. so why does not ggi provides a ggiPackPixels
>> routine?
>
>Because "ggi_pixels" are already considered to be packed. You can't
>pack them any further...
well, sort of. an array of ggi_pixels* isn't (always) suitable for
ggiPutBox.
>When you are dealing with a 8bpp buffer, your pixel values are
>actually just uint8's. Notice that the PackColors function doesn't
>return an array of ggi_pixels, but a void *, because if you pack 16
>colors, you'll get 16 bytes of pixel data back if v is a 8bpp visual,
>you'll get 32 bytes of data if v is a 15 or 16bpp visual, etc.
right. so you can not produce a ggiPutBox-compatible array from a
ggi_pixel array right now. that's the whole point. you need to pass
through ggi_colors first, even if you're code doesn't need it.
>Not even all the ggi_pixel's which actually use all 32 bits of the
>uint32 are the same... they can vary based on the visual's pixelformat
>and have different meanings, like for example, they can have rgb or
>bgr ordering on the bits that are used.
that's why you need something like ggiPackPixels (or wathever other
name) to go together with ggiPackColors. because you can't know how to
pass from ggi_pixel* to void*.
>> it seems it would be much more efficient, and easier/shorter
>> to implement than ggiPackColors. any particular design reason?
>
>What you are asking is for GGI to define a "standard" 32 bit
>pixelformat and define functions to operate on that pixelformat. GGI
>isn't in the business of defining arbitrary standards... everything in
>the API has been distilled to avoid doing something like that.
no. what i'm asking for is to be able to work with ggi_pixel* and to
be able to transform it into void* at will. the code would look like
ggi_pixel* colors_i_will_use
ggi_pixel* array;
void* buffer;
ggiMapColor(colors_i_will_use)
array[i]=whatever color i want from colors_i_will_use;
...
buffer=ggiPackPixels(visual, array);
...
(render buffer a few times, modify one or two pixels of array)
...
buffer=ggiPackPixels(visual, array);
...
(and so on)
what i gain is not having the overhead of mapping colors with
ggiPackColors, and i also gain memory for not having to allocate the
much larger ggi_color array. one important point is that
ggiPackColors already does ggiPackPixels indirectly
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]))
the first line is a mere convenience to avoid working with ggi_pixel
arrays (but some people actually want to work with pixel arrays). the
second is ggiPackPixels. so there is (modulo intermediate array) a
'ggiPackPixel' function implemented in every ggiPackColors routine!
there is no reason whatsoever for not having ggiPackPixels. there are
many reasons to have it. and, as you can see above, it is weird to
have one and not the other. why can i use ggiPackColors and not
somehting like ggiPackPixels when i want it? everything is
implemented! why am i forced to go through ggiPackColors just to have
a ggiPackPixels implicitly called, with all the overhead of mapping
colors? it's very inconsistent, and i really think it is something the
api should support. (as an aside, ggiPackColors should also support a
NULL void* and allocate space as needed, otherwise one always has to
allocate void* from the worst case --- which is a bummer in low-memory
systems)
>The most direct way to do what you want to do would be to just render
>your glyphs in 8bpp grayscale, and then render a palette to the visual,
>and get it back out with getbox, then when you want to look up a color
>when you are rendering, do this:
no, because i will render the 'grayscale' in different combinations of
foreground/background colors. also, as you can see from your code, i
will have to get away from all ggi is supposed to give me: *generic*
(which means format-independent and that i should not have to worry
with bpp, pixel size, etc) and efficient graphics capabilities.
ggiPackPixels, something which i am ever more convinced should be in
the api (since it's already there hidden), would solve this problem.
to see how weird it is as it stands now, just imagine this dialog:
a: hey, i have an array of ggi_pixels, can i transform it into a
ggiPutBox ready array?
b: no, but you can do that with ggiPackColors.
a: what does it do?
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.
a: huh? are you serious?
b: well... you can always reimplement the second part by hand for all
cases all over again.
a: are you on drugs, dude?
>switch (db->buffer->size) {
>case 8:
>case 16:
> /* as above but using (uint16 *) */
>case 24;
> /* more complex code to pack to 24 bits */
>case 32:
> /* as above but using (uint32 *) */
>}
>ggiPutBox(v, xpos, ypos, fontwidth, fontheight, buf);
>
>... or if that consumes too much memory just cache the more commonly
>used colors and generate the rest on the fly.
ggi already has everything internally ready to do that. it *does*
everything on every ggiPackColors. the code i'm writing is using
ggiPackColors now. it will be more inefficient. but it is kind of
pointless for me to implement a big switch statement with lines
copied from pack.c. it is the opposite of generic... so while ggi
doesn't support something like ggiPackPixels i will continue to use
ggiPackColors with its inherent overhead. if it turns out nobody's
convinced there's a need for ggiPackPixels (if not for anything else,
for api consistency), then too bad for me. but you have to agree that
it is at least strange having ggiPackPixels already implemented
everywhere but totally inaccessible.
cheers,
--
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
