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.
> 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]))
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).
The values from the call to ggiMapColor are cast into the right size for
the buffer one by one.
> >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.
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.
> 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.
"Generic" and "efficient" are two goals we have to balance against each
other. 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. 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.
The code I offered would be more efficient than using an array of ggi_pixel
because it would not waste the space to store 32-bit ggi_pixels when you
are using an 8bpp visual. It would also integrate the algorithm that
applies the fgcolor/bgcolor to the 8bpp grayscale glyph with the
building of the putbox buffer, which gets it done in one transfer of the
data rather than two (algorithm -> putbox buffer
vs
algorithm -> ggi_pixel buffer -> putbox buffer).
Doing it this way also allows for the optimally fast algorithm -> directbuffer
to be coded in if the visual has a db.
> 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.
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. :-)
--
Brian
