On Wed, 7 Jun 2000, Jon M. Taylor wrote:
> ... Suggestions on which blend ops I should tackle next in the pixel
> stubs are welcome - I've got no preference now ...
I'd really like to play with the alpha channel for buttons, menus, etc
inside OpenAmulet (more precisely, add an alpha component to Am_Style-s).
But IIRC you already implemented enough for this...
> I'm considering adding the following abstractions (back) into
> LibXMI: Cursor handling and multiple cliprects. These abstractions are
> present in X but were absent in the original LibXMI codebase because XMI
> was supposed to be "just a drawing library". Well, I think there's a case
> for bringing them back now. The cursor support [.........]
> it would be awfully nice to have something that
> worked. [...] And at least the cursor pixmap will be far more flexibly
> typed and accelerated than the original X cursor drek. The GUI people
> (OpenAmulet?) can sure use cursor support too.
Yep, Am_Cursor(Am_Image_Array("mycursor.gif")) works under X11... Some
cursor support in GGI would be used immediately. In fact, it seems the
cursor is the ULTIMATE thing from the USER point of view! ;-) (You know,
the guy with the mouse that does not know what a computer program is and
always complains that the mouse blinks and does not go fast enough).
> Multiple cliprects are also supported under X, and since there are a
> variety of ways to accelerate them depending on the target environment, I
> want this one back too.
What do you mean by "multiple cliprects" ? Clipping to a region (e.g. the
ability to store a clip region in the miGC) or clipping to a simpler
"array of rectangles" ?
In the first case (clip to a region), it would be nice if such regions
could be compatible with the ones used in LibGWT (note that I don't mind
using another implementation than the one in LibGWT). However, the
relationships between LibXMI-related regions and LibGWT-(and
windows)-related regions should be clarified.
In the second case, the ability to use an "array of clip rectangles" (with
potentially better acceleration than successive calls-and-change-cliprect)
in the drawing lib (i.e. LibXMI) could be very useful for LibGWT ! (Look
how ugly libgwt/draw.c looks like !). And it belongs more to the drawing
library than region calculation (which, strictly spealing, does not belong
either to a windowing library btw...)
Personnally, I'd favour the second simpler approach. (You could try to
generalize later if it seems profitable.)
> And finally, a tough architectural question: should we hide the
> miPaintedSet type inside the stubs code, instead of exposing it and pasing
> miPaintedSets around like footballs at the application level as we do now?
> An miPaintedSet is a collection of span sets, and was nominally intended
> to be a convenient cache object for prerendered spans in X.
> [...]
> AFAIK we mostly handle it the same way X does. However, since we
> became a LibGGI extension, span-based rasterization is now nothing more
> than a convenient internal rendering technique for the XMI stubs library.
> If we use a target which directly accelerates whole triangles or polygons,
> we won't need to deal with the individual spans anymore. This would be
> nice, because almost every XMI drawing function now takes an miPaintedSet
> pointer as an argument. This would also make possible the removal of the
> miCopyPaintedSetToVisual() function.
I have no clear opinion on this personnally.
On the one hand, hiding the miPaintedSet from the application altogether
does not seem very harmful to me at this point. As you say, a miPaintedSet
is used nearly the same way as a ggi_visual (with LibXMI initialized on
this visual). So you could simply hide the painted set inside the visual.
For example, in my current OpenAmulet-on-GGI source code, no important
modification would be done.
On the other hand, in the original XMI implementation, the painted set is
color-depth independent IIRC, no ? So, it may be useful to, e.g. generate
a painted set containing a GUI button and use that painted set to render
the button subsquently ? It is not evident to me that this would generate
a significant performance improvement (maybe for very complex widgets in a
multiple screen layout with a lot of moving windows -- so not the general
case ;-).
Another interesting usage would be for offscreen GUI windows. But I really
wonder if the additional complexity of manipulating miPaintedSets from the
application would be worth the effort when one can also use
memory-visuals. They are pixel based and color-depth dependent, but this
is a very small disadvantage in our modern world, with plenty of big
textures and large video memory...
In summary, it seems to me that the original intent of miPaintedSet (cache
object of prerendered spans) is not so much useful nowadays as graphic
cards become more and more powerful and autonomous. But, note that I am
really impressed by the quality of the implementation of such abstraction
inside XMI's miPaintedSet -- really a nice piece of code! So, internally,
I'd keep that abstraction -- at least for aesthetic pleasure.
> However, this is a fairly radical departure from the X roots XMI
> comes from. I think it is a worthy change, but it will require every XMI
> function call to be rewritten to remove the old miPaintedSet references
> and other associated applications code. I'd like to get the pain over
> with soon, while there's not yet too much code which depends on XMI. Any
> objections from those using XMI? I won't be doing this tomorrow or
> anytime soon, but be prepared for this if you don't speak up.
Frankly, I am not afraid of such an evolution either. As an example, if I
guess correctly your modification will turn this code (extracted from
OpenAmulet drawing layer, method Am_Drawonable_Impl::Draw_Rectangle):
=============
miPaintedSet *paintedSet = gwtmiNewPaintedSet(gwt_window);
miPixel pixels[2];
miGC *pGC = gwtmiNewGC(gwt_window, 2, pixels, 0, 0L);
pGC->pixels[0] = 1;
pGC->pixels[1] = 18;
miRectangle rect;
rect.x = left;
rect.y = top;
rect.width = width;
rect.height = height;
miPoint offset;
offset.x = 0;
offset.y = 0;
gwtmiFillRectangles(gwt_window, paintedSet, pGC, 1, &rect);
gwtmiCopyPaintedSetToVisual(gwt_window, pGC, paintedSet,
offset);
=============
into this code:
=============
miPixel pixels[2];
miGC *pGC = gwtmiNewGC(gwt_window, 2, pixels, 0, 0L);
pGC->pixels[0] = 1;
pGC->pixels[1] = 18;
miRectangle rect;
rect.x = left;
rect.y = top;
rect.width = width;
rect.height = height;
gwtmiFillRectangles(gwt_window, pGC, 1, &rect);
=============
So, in fact, this evolution will induce a simplification.
The only drawback I see is the impossibility to cache GUI objects. But
IMHO such possibility would not be easy to use in a GUI library.
As I said previously, I'd keep the miPaintedSet abstraction internally;
because it's a nice piece of code (even though a little historical).
Externally, I don't think it is so useful nowaday (unless you want to
sort the spans and control the monitor tube ray directly in software
[1] ;-).
> In any case, any and all feedback is appreciated.
In any case, thank you very much for this work over XMI and GGI. IMO,
that's a successful wedding, and you celebrated it. :-))
Rodolphe
[1] BTW, with a 3-colour laser tube and a big wall (20mx10m), it could
make a very nice demo... :-))
