On Mon, 20 Mar 2000, Andrew Apted wrote:
> Jon M. Taylor writes:
>
> > Bugreports and patches are appreciated.
>
> Okidoke: demos/demo gives me a short line of three dashes on the
> screen, then it segfaults with the missing symbol as you said.
See my other post about using the newest CVS sources.
> xmitest segfaults immediately with a missing symbol.
xmitest is broken. Use demo.c.
> > The first and most important problem area is contextual clashing
> > between LibGGI and LibXMI. LibGGI's basic unit of context is the
> > ggi_visual, while LibXMI stores contexts in three basic types: miGC,
> > miCanvas and miPaintedSet. An miGC stores styles for dashes etc as well
> > as some pixel typing abstractions, an miPaintedSet is an opaque type which
> > holds span descriptors in the current XMI soft-implementation, and an
> > miCanvas encapsulates a "drawable" (DirectBuffer) and a set of rules for
> > drawing a PaintedSet. Only the miPaintedSet type is really designed to be
> > swapped out for another opaque type, and that at compile time. All of
> > this mess has to be reconciled with the ggi_visual concept, either by
> > removing one or more of the XMI context types and placing their member
> > fields into the ggi_visual private structs, or by figuring out how to
> > properly encapsulate the contexts inside of each other.
>
> I think it depends on what you are doing with XMI. Are you creating
> something that is supposed to be compatible with existing programs
> that use XMI ? (I'm guessing no).
Well, there is no reason to change the API any more than we
absolutely have to. But yes, we can change what we need. I have already
made changes and will make more.
> If not, are you creating something new based on the old XMI code,
> something new which sits nicely on the side of LibGGI as an extension,
> with an API that is "inspired" by XMI ? (I'm guessing yes).
Sort of, yeah. Like I said I'm not planning on making any huge
changes except in three areas:
* The current simple compile-time intraface bindings will mostly be tossed
out in favor of GGI-style runtime target API bindings.
* The body of the code in general is being heavily refactored to remove
old non-ANSI compliant code and to fit in with the general GGI source
style.
* The user API is going to have to change to rseolve the contextual
clashing as per this post.
> If so, then you're free take a hefty axe to the crufty preprocessor
> hackage (autoconf can handle such things much better),
Yes.
> and to
> generalize the needlessly non-generalized XMI drawing abstractions.
Only a few nips and tucks, here and there. One of the major
advatages of this API is how closely it maps to the X11 API. We don't
want to break that unless we have to in order to make things work
properly.
> Still with that assumption:
>
> - I think miGC should just be internalised as a single GC, like an
> extension to LibGGI's normal GC.
Right, I think this is the way to go.
> That makes it consistent with
> LibGGI and simplifies simple applications, with the downside that
> complex applications are potentially more complex and slower with
> GC thrashing.
XMI has functions for managing ellipse caches. I don't know if
you can cache non-ellipse shapes, but if not we should code it.
> - The miCanvas is just the ggi_visual_t, like you have now.
With more private data members to throw into the extension private
struct....
> - The miPaintedSet is the interesting one. I think support for
> multiple painted sets is worth having, you could imagine a game
> where each painted set is an on-screen object.
A PaintedSet seems to be a sort of generic intermediate rendering
form, generically typed and handled. Neat idea, I could use something
like that in LibGGI3D instead of void * |->. It would be a nice way to
set up 2D rendering chains along with texture/stencil/alpha/clip/etc
buffers.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
