On Thu, 16 Aug 2001, Curtis Veit wrote:
> Thanks for pointing this out Thayne!
> and ... good work Brian!
Well, don't congratulate me yet. The code isn't quite complete,
and I'm not sure if/how well it works, because apparently my
riva and matrox are both too old for the directfb drivers, and
there is no radeon driver yet.
But, the daring person with the right card may be able to figure
any remaining issues out. Except for the macro magic that
counterfeits DFB data structures from their internal headers,
and the lack of verbose documentation on the DFB driver guts,
the code is pretty straightforward. Solving the dlopen issues
by discovering GGI_DLTYPE_GLOBAL was the last really tricky part.
(That and I still am not sure whether I'm doing the right thing
with bgcolor.)
> I have wondered from time to time
> why the GGI and DirectFB teams were not working closer.
I think us GGI folks turn our nose up at the DFB API for various
reasons, and the DirectFB folks don't want to get mired down in
the complexities we incur over here by striving for the perfect
abstraction and for detailed user configurability. (And, the
same goes for KGI as making graphics drivers secure and
pseudo-UDI-compliant requires much more effort.)
We have to face the fact that people working on an actual project
with a timeline can only afford the time to code minor enhancements
to GGI/KGI. My hope with this code is that DFB driver authors will now
be able to appreciate that their drivers will work for LibGGI
as well, and it will encourage them to write more. Hopefully their work
will also serve as sample code, and perhaps in some cases a source
of actual code, for KGI. Everybody wins, IMO.
> Checkmode seems rather central to resource and mode management.
> How do the DirectFB guys do without it?
You set a mode, it either suceeds or fails, but you don't know until
you actually try -- which is fine for everyday simple use where an
application sets a mode and sticks with it until it terminates.
They also are rather restrictive on the pixelformats they support.
That may chafe us here in ggi-land, but concentrating on the
"best bang for the buck" does have the effect of speeding their development.
> Brian, it sounds to me like you are probably more aware of differences
> between GGI and DirectFB than the common developer. Any chance you
> would compare and contrast the two? (Sorry to make the question sound
> like an exam, couldn't resist.)
Well, I only did a cursory look at DirectFB's API, enough to see that
it was not a suitable target.
What DirectFB has that LibGGI currently doesn't is:
1) Blt/ROP/Alpha support
2) Motion Video support
3) management of layers (beyond what we can do with memvis/display-sub).
DirectFB is best suited for persons developing embedded apps or not
caring if their program is very portable.
GGI of course is more portable across OS and display system than anything
else. It's also a bit more mature in certain areas (e.g. they only just added
vc-switching support to DFB, and it will probably not be quite right
for a little while unless they take a long hard look at our linvtsw.so)
> (and tend to prefer GGI to a small extent as a result.) I'm still
> a beginner with both APIs and have a hard time seeing advantages
> and disadvantages to the different directions taken.
DirectFB won't tap your hardware to its limit, and will probably
be a bear when graphics resources run low, but if you are satisfied
with the environments it will run under (overbudgeted hw, linux only,
probably some architectural restrictions) and you need features GGI
does not have right now and cannot afford to wait for GGI to develop
those features (and it will be a good long wait, I must be frank)
then DirectFB is an OK choice.
--
Brian
