Fresco M1 Released

rajan r writes "The first release after 18 months, Fresco, previously known as Berlin, released M1 or Milestone 1. The release notes here, screenshots here. The original 'press release' follows: 'I'm proud to announce that milestone 1 of Fresco (formerly known as Berlin) has (at long last) been released. A lot has changed since the last release, but this isn't that surprising, since the last release was more then 18 months ago; most of the real work for the past few months has been behind the scenes (changing hosts, a new web site infrastructure, improved build system, an issue tracker (hooray!), better documentation (and more to come), etc.). Source (no packages at the moment, but debs will be available soon, and the tree contains .spec files for building your own rpms) The name change. Enjoy! -- Nathaniel '"

good thing

[Anonymous Coward]

The only thing holding back Linux from World Domination is X's suckiness and slowness. 97.5% of the people using X don't need network transparency which slows X down by 15% in some cases. Unfortunetly, too many apps and GUI libraries depend on X (ex. GTK and QT).

You know, Fresco...doesn't ring a bell?

[Anonymous Coward]

Okay, how about Berlin? Still doesn't ring a bell? You mean that you don't know about this obscure package referenced only by unknown product names that the unbelievable overwhelming majority of the public has no knowledge about? Good then, we won't bother including a simple description of what the hell it even is.

P.S. It's a system for tracking calories from consumed donuts.

CORBA?

[khuber]

Am I the only one who thinks CORBA for local system calls is gross? I wonder what the overhead to draw a pixel is like.

(Okay, actually I think CORBA is gross, period.)

-Kevin

Re:good thing

[Doug Neal]

The only thing holding back Linux from World Domination is X's suckiness and slowness.

No, it isn't the "only thing holding back Linux" at all. There are many things holding Linux back from this (dubious) goal and X just isn't one of them :P

Re:CORBA?

[obi]

Except that Fresco doesn't use calls to draw a single pixel.

It's the single issue that people take most issue with - it's truly bizarre.

If Fresco needed to drop CORBA they'd have to reimplement a system similar to CORBA to have the same features, only to satisfy NIH syndrome. And they'd drop all the work that has gone into CORBA's design _and_ implementations (there's some good well performing ORB's out there)

In other words, CORBA is a good fit for a project like Fresco.

Check out these links with some answers to your question

- http://wiki.fresco.org/index.cgi/ArchitectureQuest ions
- http://wiki.fresco.org/index.cgi/MicroGUI
- http://www.fresco.org/introduction.html

Re:Some basic facts:

[t_hunger]

You are right: We need to do roundtrips for the few calls we need to make. Fortunately Fresco is designed not to need much kommunication in the first place: We are not poshing pixels around. The Display server has all the information needed to rerender the (transformed) GUI of any application running at that server. The only calls between client and server happens when the server informs the client about a statechange.

The demo application uses a bandwith of about 1.9kBit/s... That's because the server pings the clients to check wether they are stoll alive.

Getting higher speeds out of Linux graphics

[FeatureBug]

In an earlier comment somebody said, "Fresco is not X: Yes, we do not extend X. X is good, we do think so too, but it has certain shortcommings we do want to adress. Improving X is not an option: We'd need to carry along tons of code we do not need and blow the code size out of proportion (example: xlib, networking code)."

X may be good but sometimes it is simply too slow and, worse, the documentation does not go out of its way to explain properly the speedups that are available.

Ok, there's shared memory pixmaps and shared memory images [reptiles.org] but the documentation is incomplete.

When you need speed and don't care about hardware-dependency you can use Direct Graphics Access module - DGA. But where's good documentation for DGA? Is there anything faster than DGA in X? Where's the good documentation?

For God's sake

[qwijibrumm]

Everyone is saying,
1. "Why?"
2. "What's wrong with X?"
3. "It looks like crap."

Nobody realizes the answers are easy.
1. Why not? They want a better, simpler windowing environment.
2. Read the page. There are performance issues, resolution issues, and network issues. They also hope to add an X compatibilty layer at some point.
3. It's not done, not by a longshot.

Frankly, a rival project is a good thing. Good luck to Fresco for doing something that no one else dares, writing what could turn in to an X substitue.

Re:CORBA?

[khuber]

I realize that Fresco is high level and vector-based. The pixel question is just to see what the most extreme overhead would be. But then again, how would Fresco support games running in a window?

I'm just not sold on the idea of using CORBA for a component model in this manner. Gnome does this too so it's not a new idea to me. I have read many arguments, but I'm still skeptical. Why can't I have a proxy API that makes local library calls or CORBA calls, depending on what is needed? A language that doesn't want to call native code can use CORBA. There are also some "philosophical" issues about the realities of network transparency as I mentioned in another post.

-Kevin

Re:good thing

[Doug Neal]

Nonsense. The orignal poster was referring to the supposed suckyness of the X protocol and design. While it does have its drawbacks and disadvantages, they have precisely nothing to do with the usability and user friendlyness of the Linux desktop. You can build a really great app on top of X - Mozilla for instance - or you can build a real bitch of one that your average Mac or Windows user wouldn't have a clue about, e.g. XEmacs.

What will be (and already is) making Linux suceed on the desktop is a friendly desktop environment, such as KDE. The underlying windowing system that it uses to draw on the screen is largely irrelevant.

X is not getting in the way of the Linux desktop succeeding. It has all the important features now: font antialiasing, video, on the fly resolution switching, several great looking toolkits to choose from, and the network transparency is just a bonus. In fact I'd find it pretty hard to work without it.

Re:You know, Fresco...doesn't ring a bell?

[JabberWokky]

Yeah, I get pissed when I go to sports sites and they talk about all these teams and games and RBI, yards passages and other technical terms. I expect them to explain it to me in every article summary too. Fuckers. Tell you what - you go beat up on the sports sites for assuming you know something about sports, and I'll go beat up on the technical sites for assuming you know something about tech.

(Oh and I *REALLY* hate the sites that link to other sites that might have further information... like they expect me to *read* something about the subject. Ha! FAQ and search engines? Not for me my bucko - I want it spoon fed!)

--
Evan "Played golf and cricket in school, still have only a dim idea of how (American) football works"

deeper issues

[Anonymous Coward]

Surely there are deeper issues with a Vector based display that is resolution independant... The rest of the computing world does not use this approach, so how do you remain compatible?

I am not talking about software applications here, but everyday things like webpages (images in a web page are not generally resolution independant) and games.

Hardware is the same. My monitor is an LCD device with exactly 1280*1024 pixels. With a 100% vector display it would be awful to look at all day. I like the ability to be able to turn on or off 1 pixex, or subpixel, on my monitor.

You end up with an awful and awkward looking experience just for this "feature" which actually isnt all that important.

Re:An intro that actually introduces would be help

[bettlebrox]

I agree, an intro as to what Fresco is would have been useful. And would probably have saved the owners of http://www.fresco.org/ loads in bandwidth costs. I'd suggest that the slashdot editors consider a brief introduction on each article or lay down some guidelines when posting articles so readers aren't doing a lot of headscratching. Luck!

Re:CORBA?

[obi]

For things like movie playing they'd take a shortcut indeed (SHM). I found this in http://wiki.fresco.org/ArchitectureQuestions

"... In the exceptional case that a client application requires serious bandwidth to the videocard and there is a good reason not to move drawing code to the server (like, say, a game) there's nothing preventing an X-like shared memory segment from being negotiated between the client and server. ..."

I think that's what's being done when using XGGI in Berlin (running X in a window in Berlin)

As for what Gnome does - imho they're using corba as a network protocol, not what corba was intended for. They write wrappers (bonobo) around the corba binding (admittedly this is necessary because the C corba binding is horrible)

As for your comment: "Why can't I have a proxy API that makes local library calls or CORBA calls, depending on what is needed?" - a decent ORB does this already for you.

OmniORB4 is a very well-performing and compliant (and GPL) ORB - they state on their webpage (http://omniorb.sourceforge.net/cgi-bin/moin.cgi/O mniOrb4DevelopmentStatus)

"... When a servant for an object is in the same address space as the client, omniORB uses a colocation optimisation that makes the call significantly faster than a remote call. However, to adhere to the CORBA specification, there is still a fair bit of work involved in a local call, including locking to make sure everything is thread safe, per-thread data access for POACurrent, and all sorts of other things. This adds up to mean that a colocated call is significantly slower than a direct virtual function call would be.

omniORB 4 supports a proprietary POA policy that allows local calls to shortcut all of this, resulting in local calls that are almost as fast as virtual function calls. ..."

Fresco has used this "shortcut" and it can speed everything up quite a bit.

Comparison to PicoGUI?

[Ian Bicking]

PicoGUI [picogui.org], discussed here recently [slashdot.org], seems very similar to Fresco. What is the advantage of Fresco over PicoGUI? PicoGUI actually seems to be somewhat usable right now because it has been made for a very practical purpose, and has gotten real use. A library or system that isn't really used has a hard time developing quickly and responding to real (not imagined) needs.

I think it's also neat that PicoGUI supports multiple (programming) languages simply by having a documented net protocol -- language bindings talk directly with the renderer over the net, instead of wrapping some C interface.

PicoGUI is also small and cross platform. It's certainly not as old as Fresco, but it looks like they're going to lap Fresco pretty easily.

On another front -- what's Fresco's comparison to NeWS [art.net]? NeWS, a competitor to X from Sun (late 80's?), had some concepts that were similar to Fresco (and PicoGUI). Considerably more display logic was on the server (renderer). It apparently had lots of bugs and issues, but it actually did reach a usable state. Have they learned from this predecessor? Neither project seems as flexible (NeWS used Postscript for its widgets, so new widgets could be nearly arbitrarily complex)... that flexibility may have been NeWS downfall.

Anyway, it always seemed like a neat idea and an important project to learn from.

Re:You know, Fresco...doesn't ring a bell?

[nickos]

X seems to use so much video memory because the X server process allocates memory on behalf of tasks using it's services.

none

[Anonymous Coward]

You open source guys never learn anything. What linux needs to compete with Windows is a decent software installation program.. not another freaking GUI. Users want to be install a program off the net and be up and running in minutes not play around with command line switches

Why is this in the X section?

[g4dget]

I don't see what Berlin/Fresco has to do with the X Window System. Fresco used to be an X11 toolkit, but now it's something completely different.

Re:You've missed the point.

[Anonymous Coward]

None of that stuff worked because resolutions were and are now too low. But if you look at the future, the OLEDs that will run at 600dpi, the LCD that IBM just released last year, the T221, you'll see that the whole resolution game is about to change in a big way. The way scaling works now will fail to work in a heterogeneous environment where some folks have 1024x768 displays and others have 10 megapixel displays both comprising the same area, especially when both those folks want to use the same apps. MS Windows and X as they are now will break down horribly. The only programs that will look good when resolutions get that big are xeyes and xlogo. :P

Re:An intro that actually introduces would be help

[Mark Bainter]

Heh. I find this attitude bizzare. This is a news site dedicated to a specific market. Chances are, if you're in that market, you know what berlin is. However, if you don't, you can go look, that's the beauty of having the link in the story.

So, do you make comments like this on CNN? "Where the heck is Israel and what's the big deal about the west bank? Sheesh, can't you guys put a short history lesson about each area and the conflicts involved in every article?"

Re:An intro that actually introduces would be help

[Anonymous Coward]

Hey it's you again!

Maybe you should actually pay a little more attention to the news. You see the news actually introduces lesser known subjects without presuming that every reader will run off to check a encyclopaedia to see what it is. The West Bank, which is basically the news equivalent to "Linux" in the technology world (as far as commonality) might not need an introduction, and is a stunningly ridiculous example for you to bring up, however most other lesser known news stories DO have sentences describing the location and why it matters.

Moron.