I have a love/hate relationship with Fresco. Most other projects I’m interested but I’m never really drawn in. Fresco is…weird. Just weird.
I’ve been doing a bit of reading trying to understand the design behind Quartz Extreme and so on. Why? I’m getting really frustuated with X. I had hoped for the X fracas to bring about some change in the X community. Maybe even an admission that the X protocol as it stands now is outdated and perhaps a movement to a new version of the protocol. But no. Nothing. I appreciate what they are doing, (trying to get extensions in faster, drivers written faster) but my real world experience leads me to conclude that X itself needs to go.
People always say “You know what – a lot of the problems with X have to do with the drivers”. No. Not necessarily. On my sister’s computer with the latest nVidia drivers, X still _feels_ slower when compared to the GDI. 2D performance. Now, if I run a full screen GL application (UT2003) there are minimal differences. Now AFAIU, a full screen GL app simply blows right through the X protocol (ignoring it one might say) and making GL calls directly to the card. This leads me to suspect at least some of the problems in the slowness are related to X itself.
I gave up Fresco about a month ago. It was going nowhere fast, I hated the steps required to do anything with roundup (I might suggest that the simply move to a newer version of roundup) and I _really_, _really_ dislike CORBA. But, of all the things out there, Fresco and PicoGUI are the only ones with what even _approaches promise. Micah has stated publically that PG2 will only see the light of day in 2-3 years (understandable)…so that leaves Fresco. Perhaps Fresco won’t develop as fast. I think a lot of the slowdown comes in trying to develop for _everything_ and _every instance_. A system can be overdeveloped too. I know it. I’ve done it and I’m extremely susceptible to its charms. However, I’m beginning to realize that the simplest solution is often the best.
Just for kicks I logged on to IRC today and talked to hunger. I asked him if it was possible for an application written in toolkit “A” to display on a server without said toolkit. The answer wasn’t what I expected. In short:
Ans. The server provides specific interfaces of ‘widgets’. Toolkits only differ in how they implement those widgets. Doh.
How does one deal with custom widget “X” then?
Ans. The server provides building blocks to create widgets. In the case where you need to create a custom widget, send a series of buildingbox commands to create this custom widget. Hmm. Interesting. After all, why not?
But there’s a problem. Do I have to send a list of commands _every single time_ I want to create an instance of the widgets?
Ans. Iffy. Fresco’s sg is a directed acyclic graph. In other words, there can be many different paths to the same node in the sg (AFAIU). This means that the glyph “A” for example appears only once in the sg. Therefore it is theoretically possible for this custom widget (a composite grpahic) to be shared in the sg.
But what happens if the custom widget has a label that is different in each instance. Can it be shared then? (Perhaps by abstracting out the part which is common?)
Ans. No.
Here’s where it got kinda weird tho. Hunger’s next comment was:
“georgeal_: But once they are inserted into the scenegraph it does not matter how you inserted them into the scenegraph (via clientside lib or server kits).”
I’m not sure how that fits it. It would be interesting for the server to cache a series of commands upon being told that its a custom widget (at least the commands that are common) and modify it as required…
I asked whether they did compositing using the GPU (fully expecting the answer to be no)
Ans. Yes. Doh.
Hmm…they seem to have thought of this quite a bit…. Thinking again now.