On Sun, 5 Nov 2000, Lee Brown wrote:
> On Sat, 04 Nov 2000, Jon M. Taylor wrote:
>
> > There may not always BE an offscreen part of the framebuffer on
> > all targets. In particular, the targets which do not support one or more
> > DirectBuffer mappings cannot use this method.
>
> Hard to disagree with that. I guess my point is that somebody should be able
> to know what is available and use it if it is.
In a way, they can. Each target has the ability to map zero or
more DirectBuffers onto any memory-mapped buffers which are available from
the target environment, and then optionally attach these DB structs to a
list which is associated with the ggi_visual struct.
> > > I wrote a little demo (with minor changes to the fbdev
> > > code) program that allowed me to draw offscreen (outside of the virtual area)
> > > and then use ggiCopyBox to blit it to the viewable (virtual/pannable) area when
> > > needed. What am I missing here?
> >
> > Did you try it on all targets?
>
> No. Actually I've given it more thought and I appreciate the problems
> associated with this more now. Perhaps, If we could make this memory
> accessible through the normal api then it would be most useful.
If the target code does its job "properly" and maps all available
buffers into DB structs and attaches them to the ggi_visual, they will be.
But all that will be available is a list of DBs, with only some basic info
about buffer format (stride, bit depth, chunky/planar layout, etc)
available. There does seem to be a set of logical-or-mask #define
namespaces provided in ggi.h, including some for colorspaces, attributes
(alpha, text bold/italic/etc, font banks, etc), global buffer types
(zbuffer is the only one defined), attributes (write-protected, window
id), etc etc. Looks like this will be a bit easier than I had thought,
although I can see us running out of bits for subfields. There is also a
void pointer for hooking arbitrary metadata to a given DB struct.
> That way
> anything that can be done to a displayable area can be done offscreen as well.
*If* the appropriate DBs are made accessible through the
ggi[Set,Get,SetDisplay]Frame() API calls. In the easy cases when all
frames are directly mapped to persistent DBs, this is automatic once the
DBs are mapped and hooked to the ggi_visual. In the harder cases, like
when buffer mappings are mutually exclusive (like windowed VGA ModeX) or
based on a ruleset (like the Savage4 AGP buffer mapping layouts I have
been using as an example in this thread), custom ggiXXXFrame() functions
might need to be hooked in the target code.
> One way to do this might be to have a non-displayable, non-clippable frame.
> This way the user would be able to blit to and from this area easily using
> ggiCopyBox.
Right, but only the target code knows if or how this can be done.
Some targets (fbdev, KGIcon) can simply allocate a 2x virtual Y dimension
and map the second frame's DB onto the ofscreen portion of the buffer.
Other targets might be able to allocate 2x virtual X dimension and play
games with the stride. Still others might have hardware pageflipping but
only one buffer mapping window, making a hooked ggiSetPage() function
necessary. And still others (Savage4, other KGI drivers) might have both
hardware pageflipping, multiple buffer maps, and other complications. We
have to do as Marcus suggested and use the ggiXXXFrame() API functions for
this to have any hope of consistency at the user API level.
> All the user would need is a mechanism to know whether or not the
> frame was displayable and it's dimensions. A call to ggiSetDisplayFrame with a
> non-displayable frame would fail.
That's the fallback case, yes.
> I could go on, but that's enough for now. Again, I'm not the expert here, but
> take it for what it is.
You are on the right track, and so am I now (I think) |->.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
