O.K. - let's show how this can be done ...:
> 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,
Note, that ggi_pixels aren't target independent - they aren't even
mode-independent.
> 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.
I would then suggest to use a simple bit or bytemask for this buffer.
It can be modified really quickly.
However if I get you right, you wnat to do bitmap-caching for fonts ...
In that case, there is no reason to modify the buffer often. Just store
the bitmaps in there - don't bother going through it changing colors or
such ...
> 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.
For as fast as possible, There is only a single solution: Build the buffer
yourself, as long as you understand the buffer format (simple modes) and
fall back to using ggiPackColors when this is not the case.
> 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).
Yes. This works, but speed depends a bit on the mode ...
For the font case I'd rather use
GCSetForeground(bgrcol), DrawBox();
GCSetForeground(fgcol);
loop_over_array()
if (isset()) ggiDrawPixel();
> b) use ggiCrossBlit together with a memory target.
This is a simple solution to avoid having to know how to blit to _any_
mode. You just always open the same mode on the memtarget.
However this can have some nasty cases where the Crossblit gets slow.
> 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.
That wouldn't gain anything at all, or would it ? O.K. - it might be lighter
on the PCI-bus as it can burst and such ... but not really much.
Now for the "really right" solution:
It is - as always - writing an extension for bitmap-blitting.
The point about extensions is, that they have full access to LibGGI internal
stuff and can separate out individual rendering modes into rendering libs.
This allows to define a function like
BitBlt(ggi_visual_t vias,bimap_t *src,int x,int y,int w,int h, ggi_pixel color)
and the function will be overloaded as appropriate when loading the
renderlibs (i.e. when setting the mode).
Such a lib can be started pretty quickly by just having a single stub
version of the function that will do the "dumb" DrawPixel version.
And then you add "special" renderers to your liking ...
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
