Hi!
I forward this message to the GGI list as this topic is IMHO also
related to GGI.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
---------- Forwarded message ----------
Date: Mon, 2 Jul 2001 17:08:16 -0600
From: Curtis Veit <[EMAIL PROTECTED]>
To: Rodolphe Ortalo <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: [] Re: Looking for the 2.4 kgi patches (fwd)
On Mon, Jul 02, 2001 at 11:22:18PM +0200, Rodolphe Ortalo wrote:
>
>
> On Sun, 1 Jul 2001, Curtis Veit wrote:
[...]
>
> > They also worry about speed.
>
> Speed is important but it only really matters when you have something
> working...
Personally I worry more about avoiding a 'speedy' reboot than the
loss of a percent or two of frame rate on the latest game.
> > (Is there a better list to use to send tech info or comparisons
> > of approaches in Linux useful for a white paper on KGI and GGI.
> > I'd be interested in writing something up. Unfortunatly I suspect
> > I'd need a little help from the group here to do a good job.)
>
> There are many many issues, including (but not limited to): bandwidth to
> the card (for hw-accelerated commands), latency, the ability for
> manufacturers to distribute binary-only drivers and libraries,
> backwards-compatibility with XFree86, mode negociation flexibility,
> security, input-devices management, console management, etc. etc.
>
> It is my feeling currently that it is now easier to explain how KGI
> (0.9) handles these issues than to explain all the genesis of the design
I'll take some notes about here...
> (and the drawbacks/advantages). There *are* drawbacks to KGI (as with
> anything) but at least it has some clear design line (at least it seems to
> me, even if I don't always get the big picture myself).
Rather then pushing (all) the technical advantages I am thinking from
the point of view of business advantages. Portability, robustness etc.
Need to weigh the advantages and disadvantages so that people know
when to and why to use KGI/GGI. If it is unacceptable to ever have the
display go south it is worth a small performance hit to be robust.
>
> > Anyway I'm sold, I just need to get a moderatly useable version
> > going with our other software and sell management on the idea.
> > (and compile a few wiz-bang demos etc.)
>
> What do you need exactly:
> - a display-target-independent version of your software (this is LibGGI
> job in fact - and it can also probaly work fullscreen on fbdev if you need
> to :-) ?
> - or a true on-KGI version of your software ?
>
> In the last case, what is exactly the purpose: feasibility demonstration,
> speed demonstration, "special-device" (handheld, VR device) demonstation ?
Although I would like to demonstrate libggi with some pretty eye candy
(just to show that the API is useful), the main issues I need to deal with
are just proof of concept. (Pretty much what Steffen and the rest of the
crew are working on already.) Basically 1.) compile something with KGI
and see it run. 2.) Speed comparison. 3.) perhaps run two apps that
step on each other on normal frame buffer and show how resource
management works in practice.
Mostly I need to jump in, help out on development and learn the
API enough to write some code to it. Also to justify use of the
various GGI related libs for some specific uses.
Basically this will all happen given a little time. I just
wish I had started in on this earlier. I've been given a
number of good suggestions and info, now I need to get started.
Thanks for the help, we can revisit some of the promotional
aspects in detail when I get up to speed and can give the
local engineers some packaged code to chew on...
Regards,
Curtis
_______________________________________________
kgi-develop mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kgi-develop
