On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
> I think you should allow argument to be given to the raster operation,
> e.g. the alpha value, or a stencil buffer, or a color or whatever.
>
> Is there a way to define a set of 'standard' ROP definition throughout
> GGI? Thus every extension could use a generic semantic for raster ops,
> even if they don't implement or allow all of those.
Chris and I are working on this tonight. I'm going to try to abstract
what I see in the chipset docs available to me (matrox, and vgadoc).
> libxmi defines a number of these and I'm also doing this kind of thing
> in the libart renderer. It would be good to have this unified.
Definitely. I'll look at libart and xmi when I'm done and see if I missed
anything.
> > int ggiBltAddBob(ggiGA_resource_list *reqlist,
> > struct GA_ResourceProperties *props,
> > ggiGA_resource_handle *handle);
>
> Could you please explain the GA_ stuff?
See http://mojo.calyx.net/~bri/projects/GGI/galloc/
> > /* Set the given image (vis) to the blt-area with grabbing the image
> > * from a visual at pos (x,y)
> > */
> > int ggiBltSetImage(ggiBlt_t blt, ggi_visual_t vis,
> > int x, int y, unsigned char *alpha);
>
> How do you define the blit image properties? e.g. does it
> have an alpha value, z value, etc?
> Or am I missing something completely?
For negotiation purposes, A BLT is defined by three resources.
The "motor" resource defines positioning capabilities of the BLT engine
(scaling, mainly in the case of BLTs). Then each chunk of memory to be
used as a source is represented as a "tank" resource, the properties
therein defining the pixel layout (including alpha/z) and some stuff to
do with alignment in the video RAM. Finally, what I am working on
tonight is the "carb" resource which defines translations done to the
data in the tank on the way to the motor (ROPs, CLUTs, keying,
endian/format translation, etc.)
Now, that is for negotiation and acquisition of the source. LibBlit is
there to hide the unneeded fields from the negotiation process, to make
usage of the BLT engine simple by providing sensible defaults, and to
add any feilds that are needed for runtime use. The end user will rarely
work with the "motor" "tank" and "carb" directly.
We're still trying to glue it all together in a usable fashion, so
comments are welcome.
In answer to your question about varying the ROPs:
> > /* Multi-Source blitting operation. Blits all bobs from
> > * the source-list into blt using the given rop from the list.
> > * It performs stretching, if width and height are != 0
> > */
> > int ggiBltCrossBlit(ggiBlt_source_list src, size_t nmemb,
> > ggiBlt_t blt, int width, int height);
... src contains a structure that defines a buffer to blit from
and the rops to use, so the rops do vary (you can have more
than one ggiBlt_source pointing to the same buffer with a different ROP).
There is also to consider the possibility of having a function like this:
int ggiBltPolyCrossBlit(ggiBlt_source_list src, size_t nmemb,
ggiBlt_t blt, int *width, int *height);
...to queue up a series of BLT operations. As to whether to break
out the ROP from the ggiBlt_source that is a matter of whether
there will be a large enough need to vary either the buffer source
or the ROP but not both, with a large value of nmemb, such that the
memory saved/convenience is worth the extra API functions.
--
Brian
