On Sun, 30 Apr 2000, Rodolphe Ortalo wrote:
> Hello,
>
> well, I have a few questions I'd like to raise over the way I can use
> the LibXMI framework within LibGWT.
>
> First, I wonder if I should allow several paintedSet and several miGC per
> window (option 1), or hide these XMI abstractions inside a GWT window
> (option 2).
>
> With option 1, the drawing API to a window could be, e.g.:
>
> void gwtmiDrawRectangles(gwt_window_t win, miPaintedSet *paintedSet,
> const miGC *pGC, int nrects, const miRectangle *pRects);
>
> and the user application would be requested to create canvas for each
> windows and call gwtmiCopyPaintedSetToCanvas().
Well, I would have the user call gwtFlush(window_id, ...) instead
of gwtmiCopyPaintedSetToCanvas(). How the miPaintedSet(s) are turned into
pixels on the screen should opaque to the application, which should just
draw through miGCs onto miPaintedSet(s).
> With option 2, the drawing API could be, e.g.:
>
> void gwtmiDrawRectangles(gwt_window_t win,
> int nrects, const miRectangle *pRects);
>
> With option 2, a gwt_window_t window would contain a miGC, and would use
> an internal per-window paintedSet.
You could do that. However, it would be more efficient to cache
the various glyphs/patterns within the window region (gadgets, backdrops,
masks/filters, etc) as a set of prerendered miPaintedSet objects.
> These would be accessible to the
> application only through the API. (Several paintedSets per ggi_visual_t
> are still very useful, as there are _several_ windows on screen.)
Right. You can allow the application code to play with
miPaintedSets as much as it wants, as long as it still needs to make API
calls to actually _draw_ those miPaintedSet objects.
> Furthermore, with option 2, the canvas can be hidden to the application:
> this can be convenient in the case of a windowing library, I can create
> several canvas corresponding to the various rectangles composing the
> visible region of the window, and draw them in turn. Furthermore, such
> actual drawing can occur in a gwtFlush() for example.
This is preferable, IMHO.
> However, with option 1, the application retains much more control over the
> way paintedSets are managed, as well as canvas.
The application should not have access to or control over the
miGCs and miPaintedSets that are used _internally_ by the windowing
system.
> But I don't know if this
> is so interesting in the context of a windowed application.
> In fact, I find it difficult to understand exactly the role of canvas --
^^^^^^
This is where the API reworking really needs to take place. An
miCanvas is really just a ggi_visual. The current system is backwards -
the miCanvas struct contains a pointer to a ggi_visual, when what should
probably be done is to store the elements of the miCanvas struct in the
ggi_visual's private data struct. Also, the stipple and texture fields
will be logically bound to DirectBuffers which in turn are bound to
ggi_visuals, and the binary and ternary pixel merging function hooks will
be able to be hardware accelerated and thus _must_ be hookable in the
visual struct by the targets. All good reasons for getting rid of the
miCanvas type altogether and folding it into the ggi_visual private data
struct.
Proposal:
* miCopyPaintedSetToCanvas(visual, paintedset, canvas) ->
miPaintSet(paintedset)
* mi[New,Delete,Copy]Canvas() -> nothing (removed)
* miSetCanvasStipple(canvas, stippledata) ->
miSetStipple(vis, stippledata)
* miSetCanvasTexture(canvas, texturedata) ->
miSetStipple(vis, textureedata)
* miSetPixelMerge2(canvas, pixmergefunc2) ->
miSetPixelMerge2(vis, pixmergefunc2)
* miSetPixelMerge3(canvas, pixmergefunc3) ->
miSetPixelMerge2(vis, pixmergefunc3)
> especially, I see them as something pretty close to a
> (pixel-based) window. That's disturbing (for me -- with the other
> windows simultanesouly).
Not really. The miCanvas data is just additional visual context
data. If you are thinking window == rectangular viewport defined over a
superbitmap, then an miPixmap struct is what you are looking for. An
miPixmap can also represent an offscreen cache object, drawing operation
source/destination, etc.
> Maybe a compromise is the right solution (e.g.: several GCs per
> window, but the paintedSet and canvas abstractions hidden from the
> application).
Well, you _have_ to enable the use of miPaintedSets at the
application level, so that application code may implement its own
primitive rendering caches and pipelines. That is what the miPaintedSet
is there for. The challenge is to enable application code to allocate,
use, copy and free the miPaintedSets, while preserving their opacity and
their ties to the underlying target code of a given visual. The original
LibXMI did not have to deal with this type of runtime polymorphism of the
miPaintedSet type, since it was swapped out at compile time.
> Do you have any hint or ideas to give me that could help me define an API
> for LibGWT 2D drawing functions based on LibXMI ?
If you can, the best way to overload existing library
functionality in an extension is to 1) establish a one-way dependency
between the libraries (a LibXMI target for LibGWT), and B) overload the
existing XMI API hooked functions from the XMI private struct of the
ggi_visual in question with your own 'wrapper' functions, taken from the
XMI target code. The wrappers then apply transformations, clipping, etc.
as appropriate for a windowed environment, and then they call down to the
original XMI API routines.
This way you get the same encapsulation result as with your
gwtmiDrawXYZ() wrappers above, but you do not have to change the function
name or rewrite any code. There are no 'LibGWT drawing routines', only
LibGWT-enabled versions of existing drawing routines in other libraries.
This type of system is also nice for retaining access to hardware
acceleration in a windowed environment, as it becomes easy to transform
and clip in global screen space using hardware facilities, while
preserving the ability of LibGWT-unaware apps to be unaware that they are
running in a windowed vs. fullscreen (vs. cube3d.c |->) environment.
> Rodolphe
>
> PS: I can post the current API if you want (and maybe the one I'd see with
> option 2 -- if you give me some time to sketch it).
Sure.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
