What I see is a situation very similar to the WinG (Windows Game) libraries
in the Windows 95 timeframe.  These allowed a Windows app to take over the
entire screen and bypass GDI--even to the point of changing screen res and
refresh rates. Then, when you Alt-Tab'd away, or some other reason required
you to go back to other windows, you'd revert back to the normal modes.

If we can have a method by which an app can take over the screen from X, and
then give it back (or have it taken back if necessary) then the apps (e.g.
games) that need bare-metal access can do it, and those that can perform
fine within X can do that.

I'm certainly not trying to say that all apps need bare-metal access, or
that frameworks are a bad thing.  But they become bad if they prevent you
from bypassing them at need.

I'm not an X expert--I've dealt with Linux as little as possible in my
career--so I don't have ready access to the knowledge about what is
possible, what is easy, and what just plain won't work with these systems.
If we can keep X and GTK and provide a way to get maximum performance for
those apps that need it...great!

- John


_______________________________________________
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

And i agree with you, thats why in my opinion something along the lines of DirectFB should be used. This library allows developers to bypass the X and allows applications to talk directly to video hardware with a thin simple API,
no need to switch anything.
The better part is that DirectFB already has GTK+ support so less refactoring would be necessary, but thats the problem, some code would have to be rewritten but with projects like XDirectFB, wich alows unmodified code targeted to X to run unmodified, this
could be made gradually.
I believe there are many potential solutions for this 'problem' without having to hinder programming simplicity.

Regards,
Daniel

_______________________________________________
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Reply via email to