> David Pettersson wrote:
> > I just joined this list, in order to follow the project's progress. I have
> > been a happy user of the library since 1999 when I was desperately looking
> > for a simple but powerful graphics interface :).
> >
> > Anyway, I have a few ideas on how to extends GGI further, but after doing
> > some research it seems my idea about using OpenGL and GGI together aren't
> > unique (Mesa already has GGI support -- the guys in #ggi probably already
> > knew that but they were far asleep :).
Hold on for a bit and Christoph and I will be making a proposal for GGI's
own advanced 2D API, the basic ideas behind which should extend easily into 3D.
> > So, I am now without any particular idea, but I will gladly help out with
> > the development. I thought I'd start out as a reviewer to get a better idea
> > of what the code does. If anyone has any ideas, comments or suggestions,
> > please let me know.
Having just been mucking around in the source code a lot, these are some
of the major things that stuck out to me as needing doing, aside from
the new extensions Christoph and I have started (which are also in need
of work.)
1) If you value the LibGII input library a whole lot, then some work needs
to be done there. We once had two objects in LibGII, inputs and filters.
Then they were unified, but HOWTOs were never really written for writing/using
filters. Filters are the second punch in the one-two combo that make LibGII
something really special (target independence being the first.) If people
were to grasp their potential for practical application (e.g. advanced game
control tuning, input emulation for the disabled, etc.) then LibGII would
be more actively used IMO.
2) We need to flesh out generic default renderers, especially in extensions
and especially ggiCrossBlt. In many places, these have been implemented for
the common cases, but never followed through with more thorough optimization.
Part of the point of LibGGI is to take advantage of a modular system to
dynamically optimize stuff; we should be sure we have a full menu of dynamic
modules.
3) Embedded folks want to link LibGGI statically. This has been on the
TODO list for some time now. Marcus finished up some preliminary work that
makes this much less hairy to accomplish about a year ago. Basically, a
compile-time option that replaces the dl loading mechanism with a simple
table lookup needs to be added in order to accomplish this.
On Sun, 10 Jun 2001, Stefan Seefeld wrote:
> contact Jon Taylor for news about GGIMesa. Half a year ago he was about to
> add some acceleration support for matrox cards. Dunno how far he has been
> getting with that.
4) We should take the following tact as far as hardware drivers are concerned:
We need two things -- a reliable, secure kernel graphics system in the long
term (that is, KGI) and in the short term we need enough hardware acceleration
to keep LibGGI competantly fast, and to test new APIs or libraries like
GGIMesa for 2D and 3D so they are ready to use once KGI comes to fruition.
So if to-the-metal programming is your strong point, help out KGI. But for
the short term, I think we should NOT invest time in writing our own
userspace drivers, because other projects (DirectFB, DRI) are already
doing this and it really is a needless duplication of effort. Instead we
should figure out how to tap into these drivers to accelerate GGI and its
extensions (I already have some preliminary code for DirectFB drivers.)
This latter work requires a good understanding of linking object modules
and preprocessing/makefile systems. Using DRI modules will be a tougher
challenge than DirectFB.
--
Brian
P.S. to the list: sorry for the lack of activity; a number of personal
issues came up e.g. visiting parents and stuff, and I have a presentation
for a conference I must give on Thursday, and of course I am hardly yet
prepared for it :-). I will try to get back to stamping out those last few
bugs as soon as I can.
