On Thu, 6 Jul 2000, Robert S. Maier wrote:
> Hi, Jon and other GGI folks. I haven't been sending anything to your list
> (I've just been lurking), but being the maintainer of GNU libxmi, I thought
> I ought to do so now.
Nice to see you here! Sorry I never got in touch with you to tell
you about what I've been doing with your code, but it appears that you
already know.
> I released GNU libxmi-1.2 a couple of weeks ago, with very minor changes
> from libxmi-1.1.1, on which your current libXMI is based. In fact, only
> two C files got changed: mi_arc.c and mi_spans.c. The latter change fixed
> a segfaulting bug, and the former fixed a bug that sometimes caused arcs to
> be drawn in the wrong color.
Thanks, I'll have a look. I think I may have fixed the segfault
bug you mentioned, as well as a few others you may not have stumbled
across yet. The randomized-parameter primitive drawing demo
(libxmi/demos/demo.c) which comes with the GGI libxmi does a good job of
pounding hard on the API to help find obscure edge cases (usually in
mi_arc.c) which cause the odd random segfault. I still run into one
remaining stubborn one every once in a rare while (~1/50 runs), but it is
sufficiently hard to reproduce that I gave up on it. As far as the color
bug is concerned, I've reamed out a lot of mi_spans.c and replaced your
abstract unsigned int based generic color value with native ggi_pixels, so
this may also be fixed as well.
> You should be able to find the changes and merge them into libXMI very
> easily (just do a diff between the libxmi-1.1.1 and libxmi-1.2 versions).
>
> I'm really glad that GNU libxmi is being put to use.
I'm very glad you took the time to code it up in the first place.
It saved my ass on some consulting work I did a few months back, lemme
tell ya. And a few people are now using GGI LibXMI as a base for building
GUI libraries and such on top of. I think the combination of GGI and XMI
has worked out really well so far, and there's more to come.
> As distributed, it's
> pretty nearly in a stable state (I think).
> But if you make any alterations
> in libXMI that you think ought to be merged back into the upstream version,
> by all means let me know.
I've made a substantial number of changes, many of which don't
mean much outside of the GGI framework. Here's what's new:
* A massive structural overhaul to convert GNU LibXMI into a LibGGI
extension library. Tons of new framework code has been added and the
existing code has been pulled apart into the span-rendering "stub"
(unaccelerated) code and the non-specific API management code.
* The miCanvas type is logically equivalent to the ggi_visual type (basic
unit of rendering context) and has therefore been tossed out.
miCopyPaintedSetToCanvas() has also been replaced with
miCopyPaintedSetToVisual() to compensate |->.
* Currently, all XMI function calls (API _and_ internal functions, the
whole codebase) take an additional first argument, a ggi_visual pointer.
This was a cheezy way to quickly make GGI visual contexts available
throughout the whole LibXMI codebase, and is gradually being pruned back
and refined.
* The wierd reentrant arc-drawing functions have been removed, as have the
ellipse cache structures that were used with them. I plan on
re-implementing primitive caches in a more flexible and generic fashion at
some point, using abstract ggi_resource types to represent the cache
objects and using LibGG's locking primitives to serialize access to them.
* Converted pixel type to ggi_pixel as described above. It's a typedef so
existing libxmi-using code will have an easier time being ported.
* Flat-shaded spans are now rendered using the ggiDrawHLine() API call,
which results in a substantial speedup over per-pixel rendering in the
flat-shaded case when using a GGI target which accelerates hline drawing.
* The existing miPixmap abstraction has been gutted out and converted to a
pixel-typed sub-bitmap object which can reference a pixel coordinate
offset into a ggi_visual or DirectBuffer. Because the new miPixmap type
is pixel-typed, there is no longer any need for the miBitmap (1bpp pixmap)
type and it has been removed.
* A brand new type, miBlendStage has been added and an array of them is
now a member of the miGC struct, just like the array of miPixels used for
dashing. The miBlendStage struct is a three-source typed pixel filter
representation type. In addition, a rather large number of types for
representing various blending operations and their parameters have also
been added, and a few of the more common blend ops are supported in
software (currently in mi_spans.c, but will move to its own source file
soon). The little test program blend.c illustrates how to use the blend
stages.
As you can see, I have departed from the X11 roots of GNU LibXMI
in a few places, although I have tried to do this only where necessary. If
you see anything above that you want to backport to GNU XMI, let me know.
Also, If you see anything I just plain did wrong or that you'd have done
differently, I'd like to hear about that as well.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
