On Sat, 22 Apr 2000, Rodolphe Ortalo wrote:
>
> Is it possible to have several miPaintedSet per ggi_visual_t ?
Sure, in fact miPaintedSets are not tied to any one ggi_visual at
present, although this may change in the future (see below).
> If yes, why (ie: what can be done with this feature) ?
An miPaintedSet is an opaque handle to a somewhat generic
intermediate rendering result object. Currently in the stubs
implementation it contains a list of spans, but the struct definition
could be swapped out on a per-target basis using void * or whatever. For
example, the Glide target could store the polygon vertices and color
instead of a span list - much more efficient when that type of accelerated
rendering capacity is present in the target. In such a case, we _would_
need to associate a set of miPaintedSet "cache objects" with each visual,
since each visual could be using a different target.
> Why are there 2 declarations of miDrawArcs in xmi.h ? (POSSIBLE BUG: one
> of them should be reentrant and tagged _r no?)
I removed that crazy reentrant (*_r) function system. There are
better ways to implement localized rendering caches, which is what the *_r
functions were being used for. I figure that it will be a lot easier and
cleaner to attach rendering cache handles to the visual private or
miCanvas struct, and serialize access to them with ggiResourceAcquire().
> Are any special interactions to take care of between
> miCopyPaintedSetToCanvas() and ggiFlush() ?
Shouldn't be.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
