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).
> - 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).
Perhaps another approach will become more clear once Xr allows using a
surface as the source for rendering operations.
> Mostly it felt pretty pleasant to use; I didn't spend much time
> fighting the API.
That's wonderful to hear.
Thanks again for your feedback.
-Carl
--
Carl Worth
USC Information Sciences Institute [EMAIL PROTECTED]
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
