Re: [Fresco-devel] More questions about Fresco vs X

Walter Phillips wrote:
> Hello developers!
> 
> I really hate X as a graphical environment, and have been eyeing this
> project for a long time as a possible replacement.  I hope to contribute
> to this or some other such project eventually.
> 
> I've read through all of the wikis and tutorials, but I
> still have some questions about how Fresco compares to X.
> 
> 1)  I've heard two fundamental complaints about X:
>         a)  Too much bandwidth usage for network transactions
>         b)  Too much CPU utilization on the local end (which leads to the
> system appearing to be slow)
> 
> You briefly mention point A, but only just - and mention that the
> difference is unknown, and I didn't really catch anything about point B.

I believe we stress point a) a lot all over the website: since 'higher
order' concepts such as widgets are built into the server-side, there is
far less need to transmit messages between server and client, as most X
messages are of a non-semantic nature (if you define 'semantic' as all
the stuff that concerns application logic, but not the GUI internal
logistics).

As to b), that sounds indeed quite confusing, at least the way you
put it here. Key to the argument is a correct understanding of 'local':
Here is the display server, and there is the application. Right now,
even though X permits a separation between 'application server' and 'X
(display) server', a *lot* of the display-related processing is actually
done on the application's side. See point a).
So, more cleanly separate the GUI from the 'application logic' domain
means that - if you run remotely - your application server won't be
involved in GUI-internal activities such as rendering, or picking.
How that affects CPU load then depends on the kind of application /
graphics server you are using.


> 2)  One of the advantages touted by this project is resolution
> independence.  That's good, I suppose, but there are certain applications
> that absolutely require resolution dependance to work - specifically things
> that do any sort of real-time software-based rendering, such as movie
> players and some video games.

huh ? Why do video games *require* resolution dependence ? While it
(currently) certainly is cheaper to directly map to framebuffers, it
wouldn't hurt the application's functionality if it had to map to a
texture instead. (Ok, if you include performance into the requirements
you may argue that only direct framebuffer access can provide the level
of performance you need, but that's not the same as stating you require
resolution dependence.)
So there isn't any dependence, it's just an optimization. Optimizations
should be done late, and ideally have little bearing for the overal
architecture.

> In fact, these things usually work best by writing directly to the video
> buffer, which is something that X doesn't deal with very well.
> Do you have a plan to deal with that, or are you just planning on not
> letting people watch movies or play games in Fresco?

we *do* provide direct framebuffer access.

Regards,
		Stefan