On Wed, 20 Dec 2000 [EMAIL PROTECTED] wrote:
> there is just one problem. say i render the letter "A" on the memory
> visual, and that it has a different depth than the actual target. now,
> every time i ggiCrossBlit, there will be color mapping overhead (which
> doesn't happen if both have the same depth). if i render ten "A"s, i
> will have ten times the overhead of mapping between different depths.
True -- in some cases the color mapping overhead will be
the worst case of calling a function per-pixel. I think you may
find that in most cases the mapping will be done more efficiently
and perhaps efficiently enough for your purposes. In some cases,
it will be accelerated by sending the data to the card in the
memvisual's format and letting the card hardware do the conversion.
> the ggiPackColors method doesn't suffer from that. once i render "A"
> in a void* buffer, i can map it as many times as i want without having
> to map the colors every time.
You should probably keep track of and cache N most frequently used bitmaps
this way, yes. However another thing to consider is that some targets
accelerate screen-to-screen copies VERY efficiently, so copying the "A"
from elsewhere on the sreen would be the fastest possible solution. You
should consider keeping your cached "correct bitdepth" glyphs not as putbox
buffers, but in the main framebuffer, off the visible area of the screen.
This is our "poor man's video memory management" solution right now.
Andy is right in that an extension for simple rasterops would help a lot. We
used to have a function called ggiStretchBlit, which scaled during the blit.
A ggiBlendBlit family of functions that does infusion of color during the
blit would also help you. A lot of people come through wanting one particular
function in this vein to go into to GGI core (and you came by wanting something
that already was in the core :-). If they had the extension, that would
give them a place to add such functions.
--
Brian
