Carl Worth <[EMAIL PROTECTED]> writes:
> On Dec 1, Owen Taylor wrote:
> > - No ability to use a surface for the source of fill or stroke
>
> Clearly this is needed. I haven't started thinking about how this will
> work yet. Hopefully it will be quite easy.
>
> > - Couldn't control the format of group buffers, so I had
> > to use a full RGBA buffer for the stencil buffer.
>
> Can't you call XrSetFormat after XrPushGroup? Would that be an
> acceptable idiom? (Of course, the current implementation might do some
> brain-dead surface creation/deletion but that's easy enough to fix).
Well, currently XrSetFormat never creates a new drawable, just
a new Picture/Surface so all that will get you is a BadMatch.
That's from trying it just now; didn't think of doing it before.
Probably because I'm not really sure I understand the concept
of XrSetFormat. Conceptually to me, a XrState has a target
XcSurface; I can understand retargeting it at a new surface
and I can understand XrPushGroup doing this implicitely.
But the idea of destroying/modifying the current surface
does make much sense to me. Except in the case of XrPushGroup,
it doesn't seem to me that the XrState should conceptually
own the XrSurface.
Of course, this point of view is somewhat confused by the
fact that an XcSurface _does_ have state that the XrState
will need to modify. It's not just a drawable+format.
But I think the API needs a representation of
drawable/memory-buffer + format. And XcSurface seems
the the best candidate.
Maybe (extrapolating from this possible misunderstanding)
XrSetFormat should _only_ affect the format of the
buffers created by XrPushGroup?
> > - The sequence:
> >
> > XrPushGroup (r);
> > draw_3circles (r, xc, yc, radius);
> > XrSetOperator (r, XrOperatorOutReverse);
> > XrPopGroup (r);
> >
> > Still doesn't seem natural to me; I think we need to find some
> > way of moving the parameters affecting the group as a whole outside
> > of the PopGroup().
>
> I fully agree now. The above sequence really is bogus. It makes it
> impossible to isolate group drawing commands in a function and then
> apply the results of the group drawing with different graphics state
> parameters.
>
> For now, how about making the drawing of the group use the graphics
> state before the PushGroup, (as Owen suggested before). Then the above
> example would become:
>
> XrSetOperator (r, XrOperatorOutReverse);
> XrPushGroup (r);
> draw_3circles (r, xc, yc, radius);
> XrPopGroup (r);
>
> This still feels a little funny to me since it separate the
> initialization of the graphics state parameters, (before PushGroup),
> from their application, (somewhere inside of PopGroup).
Well, it's parallel to:
XrSetOperator (r, XrOperatorOutReverse);
XrSave (r);
XrNewPath (r);
[....]
XrClosePath (r);
XrRestore (r);
XrFill (r);
Though there you could *also* move the XrSetOperator later.
One other possibility that occurred to me earlier would be to
have an "current group" similar to the current path.
XrBeginGroup (r)
[...]
XrEndGroup (r);
XrSetOperator (r, XrOperatorOutReverse);
XrCompositeGroup (r);
> Perhaps another approach will become more clear once Xr allows using a
> surface as the source for rendering operations.
Quite possibly; there seems to be a lot of potential for
simple-but-rich API's in this area.
Regards,
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
