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 '"

Comments

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).

Re:good thing

[Anonymous Coward]

There is GTK framebuffer and GTK on Windows. I'm not sure how bound QT is, but as it's cross-platform too I doubt they would have any ridiculous dependancies like that remaining.

Re:good thing

[Ponty]

Network transparency is the only thing X has going for it. In fact, it's the only thing I miss on my Mac. DPS can do it on my NeXT and X can do it in Linux, I wish Apple would implement something like xhosting or NXHosting in Quartz.

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:good thing

[HanzoSan]

IF X were as good as Quartz Extreme then Linux would succeed on the desktop.

X is what is holding linux back, not lack of apps, you see people complain linux is too hard to use, and it cant be made easier until X is fixed.

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:good thing

[HanzoSan]

Can X do image transformation?
What about resolution issues? Font problems anyone?
No realtime shadows, no hardware alpha channel, software alpha channel is too slow and buggy to be useful.

Re:good thing

[Explo]

Personally, I haven't noticed any specific slowness in X for years. Some applications manage to be slow (openoffice sometimes redraws its window pretty slowly after switching workspace, as one example), but in the vast majority the speed of drawing feels practically instant, just the same than on other operating systems (or their GUIs). So I think that the only slowness that I notice is caused by the few applications themselves (or their GUI toolkits) rather than X itself.

Re:good thing

[be-fan]

Heh. I love how Apple has turned people into mindless zombies.

"Quartz Extreme" is'nt analagous to "Quartz." "Quartz Extreme" is a way to hardware accelerate window compositing while Quartz is (mostly) a software renderer to draw stuff inside those windows.

Re:good thing

[Com2Kid]

• Can X do image transformation?
• 
  What about resolution issues? Font problems anyone?
  No realtime shadows, no hardware alpha channel, software alpha channel is too slow and buggy to be useful.

And since when can Quartz do real time anything

Well besides suckage. :-P

Weee, look at the OS that needed optimizations just to scroll text! Wow I am soooo impressed. . . .

bleck.

Re:good thing

[Trolling4Dollars]

Sorry... but X is just fine if you know what you are doing. The real problems that most users PERCEIVE as X problems are actually limitations of the applications and desktop environments running on top of X.

I'm not sure what you mean by "resolution issues", but X seems to work just fine for me that way. I can easily pick from any resolution I want and switch between them with a simple key combination. And with the newere resizing features in X, you can easily change rez on the fly (as opposed to virtual rez).

Again, "font problems" could mean any number of things, but they work fine for me. With beautiful and very flexible antialiasing. Looks just as good as Windows or Mac.

You are correct with regard to there not being realtime shadows or alpha blending, but this is not likely to prevent a GUI environment from working. It's just eye candy.

One area that you missed out on was that X could really use a decent set of configuration and adjustment tools. There are a lot of features that X provides to environments and apps that people are unaware of:

-Low bandwidth compression for slow link connections
-Exquisite antialiasing
-Subpixel antialiasing for LCD displays
-Nesting X server
-Browseable DM sessions
-Ability to run apps on several different machines all on one desktop (rather than separate windows like Microsoft RDP or Citrix)

And as far as other people's complaints about speed go... it's YOUR fault that X is "slow". You are obviously picking poor quality clients, or have slow hardware or have chosen an unaccelerated X server. X (4.X and up) is very responsive if you have an accelerate driver for your card. If you have some bizarre graphics adapter, chances are that you are using the Framebuffer or VGA driver. Those are unaccelerated and depend heavily on your actual system CPU. Even though X uses TCP, it's very fast within one system. I have experienced no latency in the responsiveness of X since X 4.x came out.

The real problems are that setting X up correctly is difficult. It's gotten better in 4.x, but it's still not up to a point where Joe Average can do it. And as far as X's extended functionality, I don't think that those features can easily be used by anyone but the most advanced user. It took me a few years to understand the client/server relationship of X and why it seems like it's reversed. It also took me a while to find out about the Low Bandwidth Extensions. But now tht I know those things, I can do a lot of things with X that NO ONE can do on Windows or Mac. This proves that X is better in terms of functionality. It just needs a better way to allow users to access that functionality.

Additionally, I have no problem with the idea that people are working on alternatives to X (like Berlin), but until they have something that actually is useable for day to day work, it's irrelevant to most users. Think about this though... if Berlin and DirectFB wind up producing systems that work just as well as X, Linux will have multiple approaches to display. That is a win-win situation overall. So don't knock X until you really understand it. Chances are that once you do, you won't knock X at all.

Re:good thing

[HanzoSan]

Only Geeks and Business men care about network transparancy, come on, all the average joe wants is eye candy. Thats all Linux is lacking to them.

Re:good thing

[Anonymous Coward]

several great looking toolkits to choose from

Thats one of the problems right there. Given N apps, you'll need at least N+1 toolkits installed to make them all work. In order to get a large number of apps (the kind regular folks want to use), X will have to standardize on a single ubiquitous toolkit.

Re:good thing

[jrwyant]

I strongly disagree with that opinion: if you think about how people interact with web applications, GTK applications, Qt applications, or even simple ones using Athena etc., the widget system they use is mostly irrelavant. Most widgets are capable of being programmed in such a manner to provide a similar user experience: enough so as to make this discussion moot.

The bigger issue is to stick to standards such as where to place the "Help" pulldown menu on a window, where to place tabs or radio buttons, etc. That is the responsibility of the programmer, and not an issue with the widgets, or the fact that there is choice.

At least, that's my opinion.

Re:good thing

[Trolling4Dollars]

Yeah. Sure. That's why M$ has RDP built into Windows XP for remote support. And it can be used by MS, or even by a relative that is knowledgable enough to help grandma or big sister/brother when they can't fix something. Sorry, remote support is one of the best things that Linux could have to offer if X was fully taken advantage of. Go elsewhere with your anti-X troll. Just because you don't know how to use X, doesn't mean it's the problem. YOU are the problem. Put forth a little effort and you will see how much X has to offer.

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.

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

[Anonymous Coward]

Berlin was mentioned on Slashdot mid last year. Prior to that it was quite a well-known topic. Yeah, I guess it has been a while. Still, if you look around, you'll see people commenting that they liked the project but noticed that it wasn't moving at an acceptable pace. Some remember it.

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

[moonbender]

There's also that big "X"-symbol at the side which might give you a hint. I had never heard of Fresco or Berlin (in that context, har har), but I figured what it was about and was confirmed right 20 seconds later when I had a glance at the linked page.
Nevertheless, I agree, a subblause explaining what Fresco does wouldn't have hurt.

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

[NanoGator]

"There's also that big "X"-symbol at the side which might give you a hint..."

Just a couple of points:

1.) I have the images and stuff turned off. I'm sure other people do too. X doesn't show up on that preference.

2.) Not everybody knows what that X icon means either. It looks to me like the Xerox logo, heh.

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

[Billly Gates]

Berlin originally was started when Xf86 was still in the 3.x and was terrible slow and inadaquite compared to other gui's like Windows and macos.

Also back in the late 1990's many linux users still used pentium 1's and 486's with only 32 or 64 megs of ram! The client/server nature of X was not only inadaquate but it was considered bloated and obsolete. After all, who runs X on terminals anymore? Luckily this has changed since HP and SGI have both donated code and X came out with dri for much better performance. Without dri even the fastest of machines redrew graphics commands at a slugish rate.

If a pda and the original mac could have a better gui then X in 1/100th of the memory then it had to go. However today with fast video cards with lots of memory and dri and other improvements all the negatives on X are obsolete or do not matter as much.

I use to be an X hater untill recently. Berlin is no longer needed except on older systems or pda's. I prefer to not have the complexities of a window manager. But all gui unix apps require X so the point is useless. I do find it redicolous that in 1998 that %80 of my memory was used just for X!

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"

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

[Anonymous Coward]

Ohhh, the frothing righteousness. Guess what fucknuts: If you did a poll of Slashdot users I would absolutely _GUARANTEE_ that >99% would have no clue what Berlin/Fresco is idiot. Nice try at the uppity karma whore you bitch.

Secondly yeah links are nice, but there are billions of links on the net: People like knowing if it's worth following through on these things.

Next time just stay in your sandbox playing with the cat turds you assclown, because your pathetic attempts at being an alpha-troller just sadden us.

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

[Paul Jakma]

X came out with dri for much better performance.

Errmm.. DRI is not used for X.

Berlin is no longer needed except on older systems or pda's.

Rather ironically, it seems that Berlin is also too slow for PDAs due to very heavy use of floating point. (see the text beside the screenshot of berlin on the Zaurus).

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

[noshellswill]

Actually, FRESCO is a corruption of FRISCO which is a corruption of damned near everything.

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.

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

[Anonymous Coward]

Just a couple of points:

1.) You're an idiot.

2.) Now everyone knows it.

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

[NanoGator]

"Just a couple of points:

1.) You're an idiot.

2.) Now everyone knows it. "

I'm an idiot? At least I know how to log in.

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

[Anonymous Coward]

Your comment is profoundly uninformed -- did you ever bother to read the website and understand what Fresco actually is?

If a pda and the original mac could have a better gui then X in 1/100th of the memory then it had to go.

Don't be silly -- the display systems on the original Mac and most PDAs are both inferior to XFree, and don't use 1/100 of the memory (far more, or rather, X uses far less).

I use to be an X hater untill recently. Berlin is no longer needed except on older systems or pda's.

Uh, no. Berlin is not a "fast lightweight display server" or whatever you think it is. It's a innovative windowing system that aims to implement some radically new ideas in desktop graphics. From the Fresco introduction:

Fresco is a consistent, configurable, stand alone, modular, and device independent user interface system, formerly known as Berlin. Fresco is based on the concept of a server side scene graph. It uses CORBA, which results in the whole system being network- and language transparent.

For more information on what exactly is new and different about Fresco, the research it is based on, and more information the project, try actually reading the website before commenting, okay?

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

[Mark Bainter]

And of course, we should fill up the front page defining all the terms a minority of users might possibly not know rather than expect you to click on the damn link and find out for yourself.

Good grief.

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

[King of the World]

Then you've only been reading slashdot for the last year or two, and you don't read the comments on threads about why X sucks because someone always mentions Berlin/Fresco.

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

[Anonymous Coward]

Minority of users? You have got to be kidding. Firstly, in reality the majority of Slashdot readers run Windows (it's been shown time and time again). Secondly, of those who run a UNIX variant with X, "Berlin/Fresco" represent some fringe, oddball little unknown toolkit. I would wager that the overwhelming majority of users have no idea what "Berlin/Fresco" is, not a "minority" as you foolishly claim. People might know what Windows is, but that doesn't mean that they know about an esoteric oddball shareware program.

Is it so hard to use a standard reporting style when introducing fringe technologies? Let me give you a hint -- It'd go a little something like this:

"Mark Bainter, a well known Slashdot troll and chronic masturbator, was found nude and covered in semen in a local gay bar on the weekend."

You see how this hypothetical fictional sentence not only introduces the subject, but gives context to the reader. You see for something well known, like George W. Bush, such a descriptive modifier wouldn't be necessary, but for an unknown loser such as yourself it serves a purpose.

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

[Anonymous Coward]

So It's not a reference to the Leonard Cohen song, first we take Manhattan then we take Berlin? :-P

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

[CoolVibe]

X mmaps the video mem in it's own process space, show it shows up as a memory hog in ps and top, but isn't.

e.g. if you have one of those matrox parhelia cards with 256 MB ram in there, X will show up as using at lead 256 MB mem + a little bit. So the reports of X being a memory hog are exaggerated.

As for Fresco/Berlin, I hope that there will be an X compat layer so all my old apps will run. It's not a strange request. Lots of operating systems that don't usually run X (BeOS, QNX, Mac OS X, Windows, etc.) have an X server available one can install.

It would be nifty having a rootless X server for Fresco.

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

[cmoss]

Funny, I had no problem when I was running X under linux with twm on a 386 with 8 MB ram.

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

[nathanh]

Luckily this has changed since HP and SGI have both donated code and X came out with dri for much better performance.

HP and SGI did not contribute to the DRI.

Without dri even the fastest of machines redrew graphics commands at a slugish rate.

The DRI is only used for GLX. Maybe this will change in the future, but Xlib operations today still use the old indirect rendering model.

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

[shyster]

I thought it was Freesco the whole time I was reading the blurb. I kept asking myself, what's with this Berlin name? Then I clicked thru and realized it wasn't...Oh well. I like Freesco better anyways. =)

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

[SEWilco]

Hah. I had to read 12 replies even to this message to find someone who thought to give an answer, rather than natter on about the features of this low-calorie open soft drink.

" It's a innovative windowing system that aims to implement some radically new ideas in desktop graphics."

Berlin

[CanadaDave]

I'm wondering why they changed their name from Berlin to Fresco. Why was it called Berlin in the first place, and what made them decide to change it? Kitchener, Canada used to be called Berlin prior to around 1910 or so. Why is everyone dissing Berlin?

Re:Berlin

[Anonymous Coward]

It was called Fresco prior to Berlin. This is going back to their roots.

Re:Berlin

[Anonymous Coward]

Did you read the fucking article? There's a link right there! It's even called "Name Change"!! How difficult could it possibly be?

Re:Berlin

[Rovaani]

You could check the link titled Name change...

Re:Berlin

[Anonymous Coward]

Dave Garvy, is that you?

Re:Berlin

[Devil Ducky]

My take on the link:

The program itself is still called Berlin, only the project's name changed to Fresco.

My first guess at why has proven to be on their list, easy, available, domain name: fresco.org is much easier than berlin-consortium.org.

Also apparantly there was an old project to make a gui, called Fresco, and the original developers no longer own the rights to that name, so their paying homage to who they stole ideas from.

Re:Berlin

[CanadaDave]

Ooops, I didn't see the link at the end of the Slashdot post.

Re:Berlin

[crimsun]

If you happen to use Debian Sid, you can basically just apt-get install all the prereqs (well, that's what I'm doing). You may want to install waldi's omniorb4 packages, though. One of the main hitches is the omniorb stuff. Post-M1 defaults to ``-R ior'', and as the release notes suggest, it's highly recommended that you use that switch for both "server" and "clients."

Re:Berlin

[__past__]

I'm wondering why they changed their name from Berlin to Fresco.

Ever been in Berlin recently? It's fucking cold there in winter, the natives talk a horrible dialect, public transport is expensive, there are way too much schmocks who love living in the Reichshauptstadt because they could meet Benjamin von Stuckrad-Barre or some other aesthetically challengend famous "artist" in some lousy yuppie bar, and the beer sucks.

Nobody wants to have his toy project associated with it anymore. It was cool in the 90s, but the times, they are changing...

Re:Berlin

[CanadaDave]

Really? Thanks for the info. I went on a primarily Western Europe tour back in 1999-2000. Didn't see much of Germany, just some of the west, including Munich. I was told the Berlin was the place to be, and that I was missing out. Apparently it was a "happening place". But I guess that isn't true anymore. I have heard Prague is pretty sweet these days (at least according to fellow Canadian back-packers) so maybe I'll skip Berlin and head to Prague.

Re:Berlin

[uhoreg]

It is Guelph which used to be called Berlin. Not Kitchener.

Re:Berlin

[Otter]

Off-topic and pointless, but while considering a Google search to read more about this (my grandfather-in-law grew up in Guelph and is always talking about it) it occurred to me:

Can Canadian towns or cities in different provinces have the same name? Ottawa, BC, for example or Moose Jaw, ON?

Canadian readers, any idea?

Re:Berlin

[Taos]

As a fellow back packer from this summer, avoid the cities. They're too stressful to get around in. Go to the smaller places. They're cheaper, more culturally interesting (you'll meet people different than yourself instead of just Americans or Canadians in you case). Paris is a nightmare, I never met a spaniard (or whatever that region's name is) in Barcelona, just a ton of travelers.

My favorite places I went:
Sorrento, Italy. Outside of Naples, only a short local train ride away. Can get to all of the sites (Hurculaneum, Pompeii) and all the same boats to the islands go out of there. Take a boat to Ischia. Much more fun than Capri.

Florence, Italy, but don't stay there. Rent a scooter for a couple days and head for the hills. Beautiful countryside. Take a sleeping bag and camp around the cathedrals.

Vigo, Spain. Nobody goes there. Very friendly people, and the countryside around there is fantastic. Unfortunately, it's right in the middle of that current oil spill. Any Galicians out there want to comment?

Melk, Austria. Not terribly great, but a good place to pause before you head into Vienna.

Next trip, I'm going to do the northern half of europe. I skipped it this time around.

Wow, how off topic can I get? I'll stop now.

Re:Berlin

[AJWM]

True, Kitchener, Ontario (twin city to Waterloo, which folks on this site are more likely to have heard of) was named Berlin. It was renamed (after Lord Kitchener) during WW I for obvious political reasons.

And if you'd read the linked article, you'd know why the project was renamed Fresco, although the display server implementation retains the name Berlin.

Re:Berlin

[AJWM]

Nope. It was Kitchener.

Guelph (about 20 miles down the road from Kitchener-Waterloo, for those not familiar with the geography of southern Ontario) was named Guelph when it was founded in 1827 by John Galt. (No, not that John Galt.) Guelph was one of the family names of the British royal family.

(I used to live in Waterloo and work at U of Guelph. My commute took me past Waterloo-Wellington Airport, so on nice days I'd sometimes stop and get in some flying practise.)

Re:Berlin

[AJWM]

Can Canadian towns or cities in different provinces have the same name?

I'm not aware of anything that forbids it, but I'm having a hard time coming up with an example, either.

I'm not aware of a Moose Jaw, Ont, but there is a Moose Factory, also a Moosonee, both near the mouth of the Moose River on James Bay.

(googles around a bit...)

Hah! Found one: there's a Trenton, Nova Scotia and a Trenton, Ontario.

Re:Berlin

[Anonymous Coward]

Maybe this is offtopic... but who is John Galt?

Re:Berlin

[Anonymous Coward]

paris is lovely.

Re:Berlin

[Jon-o]

Seems almost every province has a London. PEI was very unimaginative when naming its towns (not many native settlements maybe?), so they all seem to be reused names.

Especially odd, since most of these "towns" consist of 10 houses at the most. :)

Re:Berlin

[adamy]

Well done..if you meant it.

If not, send me an email and I'll explain

Maybe in 10 years

[Randseed]

Maybe in ten years Berlin/Fresco/whatever will be useable. The last time I looked at it about a year ago, the developers were proud that they'd managed to draw simple geometric shapes.

Re:Maybe in 10 years

[bobtheprophet]

Well, look at how far it's come since then. The screenshots look like they're on the way to getting a usable windowing system, and it's not bad if they've come that far in only a year. Eh?

Re:Maybe in 10 years

[Anonymous Coward]

I wouldn't count on it. They state that Fresco is an offshoot of Interviews (derivative of, or something along those lines).

I tried Interviews in 1993/94 (almost 10 years ago) and it was pure junk. And if they haven't gotten something up and running by now it proably will not happen.

Interviews was so bad I had to give up on it and I used Motif instead. The system seemed to be solidly programmed (didn't crash, etc.), but it's design left a lot to be desired. It was just too confusing.

Btw, if I recall properly, the original Interviews name was changed to Fresco in 1994/1995, so I don't really understand where this "new/back to old" name change fits in at.

It is amazing to me how people keep trotting out the same old garbage over and over again.

And while I'm at it, what the hell is the problem with X11? From a user's standpoint on a networked environment where all the other machines run X11 then X11 is awesome.

It does what it is designed to do and as long as good programming standards are adhered to (no junky programmers applying it) it's very stable.

No, it doesn't have all the whizbang OO stuff in it, but for gods sake it's, what, 17-18-19 years or more old.

Anyway, sorry about the ranting and raving, but I do have to say I'd take Motif 2.0 (my last real X11 usage was with this version) anyday over anything based on Interviews.

Re:Maybe in 10 years

[Anonymous Coward]

I hate to knock other free software devlopers, but this project has been essentially vaporware since I first looked at it over five years ago. I would love to be proved wrong, but I can't see any visible change in those five years.

I get the sense they change their direction too much for them to stay focused on a project of this magnitude.

Re:Maybe in 10 years

[squiggleslash]

The screenshots do nothing of the sort. Indeed, I find them scary. The only two screenshots of late that show anything other than a menu are of X apps running under the new system, one inside a container window meant, presumably, to be an X desktop, the other showing them outside of the container. And the "menus" aren't terribly exciting either, those have been on screenshots since I first heard about the project 3-4 years ago...

Very peculiar, and not terribly inspiring. I think someone needs to write an app or two for the system (or port an existing app, or write a GTK or GNUstep back-end, etc) to prove it's possible.

Re:Maybe in 10 years

[Okojo]

Heh, not to mention the xterm window skewed at 30 degrees. Ahh. I mean if your boss came into your office and saw this or this, he'd wonder what the heck was wrong with your computer.

Berlin

[MORTAR_COMBAT!]

I had some early failures trying to get Berlin up and running on my system -- just compiling the (highly unstable) prereqs was a chore, let alone having to upgrade my compiler to compile Berlin. I hope this time around it doesn't take me a week to even "try" it, because I've been a steady believer in the project (well... any project to replace X).

Why...?

[bsDaemon]

How does having a bunch of transparent spinny window thingies solve the issues with X that people are always bitching about? I think i'll pass. I love X. It is, always was, and will be.

Re:Why...?

[King of the World]

You know those window shadows on OSX that everyone regards as a great way of showing windowing order? You need transparency for that, and while we have X's XRender we also have Berlin.

Transparency is also a big part of anti-aliased text. Some people like that.

Spinning window thingies isn't so important, but it shows the flexibility of Fresco. Although a window at a 45 degree turn isn't easy to use there's talk of using something like that to grab user attention. When an application needs your input rather than flashing on the toolbar or taking focus it could appear for a few seconds slightly transparent and rotating slowly - you know, like out of the Exorcist. Features like that are what's bring ing Hollywood to Linux, and I for one welcome it.

Re:Why...?

[Anonymous Coward]

Hollywood uses Linux for rendering massive computer generated scenes. This doesn't even require a monitor never mind some obnoxious window system such as this....

All the actual design is done on NT they just hand it off to a linux cluster for the rendering so really fresco would do jack squat to bring hollywood to linux.

Re:Why...?

[httpamphibio.us]

This was obviously meant in the way that Hollywood computers (ie. films in movies) have overly fancy and unrealistic interfaces and bringing some of those pure eyecandy features to the Linux desktop. Way to *totally* miss the point.

Re:Why...?

[Anonymous Coward]

Don't forget the CORBA base.

Re:Why...?

[djocyko]

You mean.... you wouldn't want the next new feature from gnome/kde/whatever to be windows that spin up from clear to opaque from the task bar to your screen? I mean, c'mon.

Yeah. Me neither.

Re:Why...?

[Anonymous Coward]

You mean translucency, not transparency...
We already have transparency :)

Re:Why...?

[Squarewav]

there is many problems with X that hopefully Fresco or any other X replacement will solve, for example in windows,MacOS,BeOS, and I think QNX if you install the latest Divx codec all apps will be able to use them, also things like cut and paste that X doesn't handle, for example you cant transparently copy images or formated Text, KDE does a OK job but you still cant cut and paste very well to non kde apps. Lack of a built in window manager is also a pain as even the most basic one adds lots of overhead to X

Re:Why...?

[King of the World]

I knight thee Sir AC of Alpha Channel.

Re:Why...?

[Mr. Slippery]

also things like cut and paste that X doesn't handle

X handles text cut and paste very well; with a 3-button mouse as the gods intended, it's much better than MacOS or Windows. Other types of cut and paste are Not Its Job. (Indeed, I question the extension of the "cut and paste" metaphor to file management; when I move papers from one filing cabinet to another, the idea of that I'm "cutting" from one drawer and "pasting" to another never enters my mind.)

Lack of a built in window manager is also a pain as even the most basic one adds lots of overhead to X

Managing windows is also Not Its Job. X provides mechanism, not policy. It is a layered architecture. This is a Good Thing.

Unfortunately many X critics simply have no understanding of what X is and isn't.

Re:Why...?

[be-fan]

What, praytell, does X have to do with copying and pasting of images or formatted text, or divx codecs? X is like the GDI. It does drawing and manages windows. That's it! KDE or GNOME provide the desktop environment. If applications don't interoperate at that level, it's the job of KDE and GNOME to fix it.

Re:Why...?

[Rysc]

The cut-and-paste you refer to is actually X selection buffer stuff. It's nice to have the ability to regurgitate what was most recently selected (very nice indeed) but don't be confused: it's NOT a clip board, and a seperate clip board is a needed thing. (Scenario: select a block of code. Cut it. Select the block of code it's designed to replace. Paste over it. Decide you don't like the change. Undo levels to return to prior state: 1. This functionality cannot be achieved with the X selection buffer).

Re:Why...?

[Mr. Slippery]

it's NOT a clip board, and a seperate clip board is a needed thing.

I've never felt a need for one, but if you do...

[holly 51] man xclipboard
Formatting page, please wait...

XCLIPBOARD(1)

NAME
xclipboard - X clipboard client

SYNOPSIS
xclipboard [ -toolkitoption ... ] [ -w ] [ -nw ]

DESCRIPTION
The xclipboard program is used to collect and display text
selections that are sent to the CLIPBOARD by other
clients. It is typically used to save CLIPBOARD selections
for later use. It stores each CLIPBOARD selection
as a separate string, each of which can be selected. Each
time CLIPBOARD is asserted by another application, xclip
board transfers the contents of that selection to a new
buffer and displays it in the text window. Buffers are
never automatically deleted, so you'll want to use the
delete button to get rid of useless items.

Re:Why...?

[Grayraven]

Actually, X does not manage the windows. It only does rendering and user input.

Re:Why...?

[be-fan]

Err, it does manage windows to the extent that it handles creation, deletion, and display. The window manager is just reponsible for movement and ordering.

Re:Why...?

[Rysc]

Well sure, but some apps don't use this properly (ie, making the selection buffer automatically add to the clip board). I was mostly trying to dispute the "who needs a clip board?" mentality.

Confusion

[faeryman]

If you're like me and have no idea what Fresco does, check out the intro, an FAQ and FrescoVsX. I was reading about this project last night, and since Slashdot doesn't really explain what everything is, these provide some answers.

Re:Confusion

[Anonymous Coward]

Karma Whore!

MacOSX ?

[mAIsE]

I am just currious if anyone has experieced compiling on OSX.

Re:MacOSX ?

[MORTAR_COMBAT!]

I had a lot of trouble compiling on FreeBSD, but that was quite some time ago. Maybe they've fixed some of their dependency and compiling problems?

Debian packages

[Anonymous Coward]

Debian packages are available from http://non-us.debian.org/~waldi/ . Note that the fresco packages require the omniorb4 packages.

Re:Debian packages

[CanadaDave]

Do these work well? Please post here if you have experience with these packages. I'd just like to hear a few comments about them before I try them out. I'm not a hard core user, but I'd wouldn't mind giving this Fresco thing a try, just for fun. After I install these debs, will I have a new selection on my X session manager? I highly doubt it since Fresco is not X! So how to I kill KDM and X, and start up Fresco?

Re:Debian packages

[Anonymous Coward]

Well, if you're like me, you just run Fresco on top of X. (It's a GGI or SDL program, like any other.)

I haven't touched the .deb's though. I run from CVS HEAD.

Re:Debian packages

[crimsun]

You don't kill KDM and XFree86, you just open $TERM and fire up ``berlin -R ior'' (if you compile M1). Think Xnest. I compiled M1 some days ago (debs weren't available then), and I'm still tracking down an omniorb3 problem where connections from localhost are rejected.

(The debs themselves use -R nameserver, btw, which is why you'll need omniorb4 + the nameserver package. I also can't comment on how well they work, but try 'em!)

Re:Debian packages

[Anonymous Coward]

So you still have to run X to use?

What a fucking marvelous X repleacement after it only requires that you USE X!

That's fucking splendid.

Re:Debian packages

[Anonymous Coward]

then fucking run it on fucking ggi on top of fucking framebuffer you fuckhead! Point of Fresco is that Fresco doesn't care what you render on. That's good thing.

Re:Debian packages

[Anonymous Coward]

You think that's bad? So far, the only way of running apps on it (it has none of its own) are to run... an X emulator!

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:CORBA?

[Anonymous Coward]

That's in the ArchitectureFAQ (find the WikiWikiWeb server). It's pretty simple. The overhead for drawing a pixel would suck. So don't do that then! Fresco passes entire paths over CORBA at once, so you don't have to worry about this sort of thing.

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:CORBA?

[Anonymous Coward]

Just use the CORBA local process calling convention standard - oh, that's right - no such beast exists.
Please OMG - write up another obtuse useless CORBA specification on valuetypes and/or yet another change to corbaloc.
Friends don't let friends use CORBA.

Re:CORBA?

[khuber]

I understand the design reason, but in practice it seems like you'd mostly be rendering to your local screen. In that case network transparency is just a performance burden.

Besides, we could debate whether network transparency even exists since local and remote resources are fundamentally different (network glitches don't affect local resources, and you generally need retry and error logic for networked resources).

I'm not trying to dis Fresco here, just think about the design tradeoffs. The problem with the X protocol is that it's low level, so even though it's a more efficient TCP-based protocol, you would be sending many more low level packets. In the end it could break even with the IIOP and marshalling overhead of CORBA since Fresco is high level.

-Kevin

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:CORBA?

[damiam]

Well, X uses the X11R6 protocol locally for drawing at a much lower level (pixel and polygon-based, instead of widget-based), so Fresco isn't that bad, relatively speaking.

Re:CORBA?

[be-fan]

But then again, how would Fresco support games running in a window?
>>>>>>>>
Most likely how X supports it: bypassing the protocol via something like the DRI.

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.

Re:CORBA?

[Gleef]

khyber asks:
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.

Several portions of GNOME, including the GNOME panel, use CORBA for local system calls. It's not quite as responsive as direct X calls, but even on a K6-400 I find it quite usable.

Desktops are so overpowered in regards to normal use, it's perfectly reasonable in my mind to use some of that power to make things:
1) More flexible
2) Easier to develop

Fresco might just offer that :-)

Re:CORBA?

[khuber]

Yeah, WebLogic's CORBA stuff handled local calls more efficiently, but it still wasn't like a function call because of the overhead you mentioned. It's good that omniORB uses a different mechanism. That sounds pretty cool -- thanks for the info.

-Kevin

Re:CORBA?

[Anonymous Coward]

I have a question about the design process used to achieve network transparency. I know nothing about CORBA or it's alternatives and have noted frequent criticisms of it's use by Berlin/Fresco every time this project gets mentioned on /. The client/server architecture of X11 and Fresco makes local display hardware a special case that gets optimised by using UNIX domain sockets, SHM, or the above mentioned omniORB 4 POA policy. Why not add network transparency later with wrapper libraries and a daemon that enable display of remote applications. It seems like we're turning network chat into function calls. Can we do the reverse?

As an analogy consider filesytems. NFS was designed to add functionality to *nix filesystems by making remote storage appear and behave like the local filesytem whose design is considered the normative standard. If the filesystems were designed like X11/Fresco we might be rebuilding kernels by begining with something like "cd file://localhost/usr/src/linux". Anything more succinct would be an assumed abreviation for user convenience handled by the shell as it handles tab completion.

Liquidate my ignorance. What am I missing?

Looks very good!

[Anonymous Coward]

Looks traditional and cool! And those "see-through" twisted-angle windows look very cool also! Am I the only one who loves new stuff with traditional look and feel?

Old news

[frooyo]

This is old news at OSnews

This is not at all near production level use. And some of the screenshots are treble, like this one - yet some other screenshots are better like this one

Re:Old news

[sdt]

And some of the screenshots are treble, like this one

That "screenshot" is not a screenshot of Fresco. It's a screenshot of gv displaying postscript generated by a very early version of the Postscript DrawingKit -- in effect demonstrating that Fresco can now print.

Re:Old news

[Anonymous Coward]

How is the post by frooyo flamebait? He/she did post a picture of a quality screenshot!

Mod me down I don't care, but his post was informative and to the point.

Answer

[kentyman]

http://www.fresco.org/namechange.html

gui

[SigmundK]

personally, i'm waiting for the graphical server previously known as prince.

An intro that actually introduces would be helpful

[Phouk]

Really, half a sentence of what this Fresco is about would have been helpful in the introduction - e.g. "Fresco is a windowing system derived from a powerful structured graphics toolkit" (from the page). This would save readers not familiar with the project from having to click on the article to find out whether it interests them, and it would reduce the slashdot effect a bit.

I know, it's a novel concept, an introduction actually introducing the readers to the subject...

Re:My only question is...

[Anonymous Coward]

Fresco is actually an Italian word for painting. Michelangelo for example used to paint frescos. Frescos are like big paintings that were painted on church wall (inside the church) for example. Do a google image search for "fresco".

Some basic facts:

[t_hunger]

Some comments on other comments that are bound to pop up:

*) Yes Fresco uses CORBA and it is a good thing. It gives network transparency and language transparency for free. Yes, we know it is slower then using raw sockets, but CORBA is the only thing available powerful enough for our needs. It's not bloat if you need the features;-)

*) 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).

*) Fresco is not x compatible now. Support for that can and will be added later. Options for that are manigfold, See our FAQ for more infos on this topic. Again: we do not see that extending X is a good idea: Extending X will result in apps using that extension not being able to run on the unextended X. Fresco apps don't do so either. Both, an extended X and a Fresco with compatibility layer can run X apps. NO, there is no compatibility layer yet.

*) We do not write drivers. We can use whichever drivers are supported by our rendering backends. That's a surprising lot. You can run Fresco in a window in X, using your XFree-driver too.

*) Fresco is device independent. So changing the screen resolution will not make windows smaller and you can print everything you can display on screen. That's a good thing (if you want your windows to become smaller you adjust their zoom factor).

*) No, Fresco is not about rotating windows. We can rotate windows, we do so in our screenshots. That's basically because making windows not rotateable would require us to write code to prevent it! And it's an eye catcher.

*) No, this is in no way ready for the end user. Developers are welcome.

That's the basic things I want to get straight early on. From earlier /. experiences I know that these misunderstandingfs/questions are bound to crop up.

Regards,
Tobias

Re:Some basic facts:

[Anonymous Coward]

we know [CORBA] is slower then using raw sockets, but CORBA is the only thing available powerful enough for our needs.

The only useful form of communication that CORBA supports is synchronous. On a network, this means that you need a full round-trip time (20 ms typical, up to 1 second) on every client/server interaction. This overhead does not decrease as machines get faster.

CORBA may be useful for some applications. Using CORBA for a window system is a sure way to fail.

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.

Re:Some basic facts:

[khuber]

The only useful form of communication that CORBA supports is synchronous.

Well, you could do one way calls with callbacks, or you could create an event queue on the client side to batch up API calls before doing a CORBA call. I don't see this as a CORBA-specific issue or a fundamental problem any more serious than how a TCP/IP based protocol would have to deal with asynchronous issues.

I think 20ms is on the cynical side. On a good local network it should easily be < 5 ms, don't you think?

-Kevin

Re:Some basic facts:

[Anonymous Coward]

We are not poshing pixels around

Neither is X.

But that's not the point. The point is that for many applications you do want close coupling between client and server. By using a synchronous transport layer (or whatever layer you think of CORBA being at), you make it impossible to implement such applications.

Another point that's important for users is that current widget sets (Gtk+, Qt) assume such close coupling is possible. By using CORBA, you make it impossible to ever implement a compatibility layer for such legacy widget sets.

(Let alone implementing X11 over Berlin...)

Re:Some basic facts:

[BZ]

Animated gifs in a web browser? Remote display of a user typing, etc? Do those involve state changes in your architecture?

Re:Some basic facts:

[Anonymous Coward]

I think 20ms is on the cynical side. On a good local network it should easily be

Yep, I was being gratuitiously nasty. Make this 2ms on a good idle Ethernet, 10ms on a local area internet, and anywhere between 40ms and 1s on a transatlantic link.

But this is overhead that you get if you use CORBA, and can in many cases avoid if you don't. Which is why I believe that the use of CORBA in Berlin is plain silly.

(I didn't know that CORBA allows batching, though, and this would mitigate my objection somewhat. I am surprised at the info, though; could you point me at the right paragraph in the spec?)

Re:Some basic facts:

[Anonymous Coward]

*) network transparency? Um, like X?
*) But not X. Ok.
*) And not X compatible. Fine.
*) No drivers but leverages existing ones. Um, like those from X.
*) Device independent. Um, like anything else running on X. Why not Display PS, or a translation layer on X?
*) Bah.
*) w00t.

Re:Some basic facts:

[Hektor_Troy]

This is, with a 99.999995% certainty, the wrong forum to ask this, but still.

Have you considdered implementing something like this abstract?

Like I said, wrong forum to ask, but I think it might be interesting for the Fresco project ... of course, It's my abstract, so I'm probably biased.

Re:Some basic facts:

[Wiwi Jumbo]

*) Fresco is device independent. So changing the screen resolution will not make windows smaller and you can print everything you can display on screen. That's a good thing (if you want your windows to become smaller you adjust their zoom factor).

That's just cool. But is the zoom factor for the whole desktop or individual programs? Being able to scale a spreadsheet to see more of it while keeping Word Processing normal would be nice. :)

Re:Some basic facts:

[0x0d0a]

Yes, Fresco uses CORBA and it is a good thing.

I haven't used CORBA, but the two distributed systems PhDs I've worked with gag every time I mention it. I figure that there has to be something wrong there. Plus, this thing has to do parameter marshalling for even local calls? :-(

We do not write drivers

After reading the FAQ, I'm afraid I still don't understand what is hardware accelerated here. If I want to render a translucent, rotated window, is this done in software?

we'd need to carry along tons of code we do not need...xlib

I wonder whether it's reasonable for only 24 bit color to be used. Half of xlib is palette/color space management.

Re:Some basic facts:

[khuber]

Sorry for the confusion, I didn't mean CORBA itself allowed batching, but that it could be done at a higher level in the application. At a simple level, you could batch keyboard events and mouse events (at the expense of smooth movement). Yes that would suck. (I just realized that CORBA overhead for mouse events might be really bad.) I think I would prefer a binary TCP protocol like X but higher level.

Re:Some basic facts:

[Ian Bicking]

...I'm afraid I still don't understand what is hardware accelerated here. If I want to render a translucent, rotated window, is this done in software?

I believe it is coded in terms of OpenGL -- that is, the drawing primitives are OpenGL calls. So presumably someone else writes the OpenGL layer, in effect an accelerated driver, and Fresco just uses it.

Re:Some basic facts:

[t_hunger]

A animated gif is just a picture, isen't it? Why should your clients state change? Of course it would need to change if you'd need to syncronize somehting with the gif's update cycle, but for a ad in a webpage that's usually not necessary. So: Usually no communication needed.

Text is a somewhat more complicated matter: Text changes need to be communicated back to the client. So there's a roundtrip hidden here. That's not as bad as it might sound: The server needs to cache the text anyway (needing to store all information needed to redraw and all), so usually you will do a 'block-transfer' at some point (aka. all changes in lines 20 to 30).

Regards,
Tobias

Re:Some basic facts:

[t_hunger]

Internally fresco uses a device independent format to store all graphics. The internal fromat is rather powerful, featuring complex object (complete meshes and such).

This device independent graphics is passed to a 'DrawingKit' when it needs to get displayed. This DrawingKit turns the internal representation into something the hardware can understand. So far that's plain pixels, Postscript or OpenGL. With plain pixels there's not much to accelerate... But using OpenGL speeds things up tremendously: All the DrawingKit has to do is accept a mesh, hand it over to OepnGL. That will use whichever acceleration your card offers...

The speedup is significant. On my lowly GeForce2 Go it's about 15 times faster then plain software rendering.

Re:Some basic facts:

[t_hunger]

In principle every graphic can be zoomed. Lines, 3D Objects, windows, buttons, pictures (for example icons) even the whole desktop is a graphic. Does that answer your question? ;-)

Re:Some basic facts:

[t_hunger]

Replace users with develeopers and I can agree with you to some degree Fresco is way different from X, so developers will need to rethink their practices if they want to use Fresco. That's somethiong of a big concern to me, but 'bending' the architecture to be more in sync with 'traditional' GUI environments so developers will feel more comftable does not feel right. I do hope that we might be able to hide some of the differences behind some client-side library... but even then rethinking will be necessary for developers. I doubt that users will have such problems.

To realize a GTK/QT you'd do a clientside library. So you can have a rather close bound between client and library. They won't use CORBA to communicate, just like those Toolkits in X don't. So I fail to see your point.

A X on top of berlin will of course need to use the X-protocol. So how does CORBA get into this picture?

Re:Some basic facts:

[t_hunger]

Not really:-)

I just read your abstract. I find it a bit limiting. For example I do not see the need to restrict a windowing system to (one) keyboard and (one) mouse. Of course you can field useability concerns (more then one keyboard/mouse cannot get used at any one time, so it's a unnecessary), but what about graphic tablets, data gloves, etc? Those should be useable with a system designed today.

Gesture handling is of some concern to us. I personally prefer the BeOS-way to handle and preprocess events here to what you propose though.

I have myself not spend much time on thinking about clippbords and such. So I cannot aomment on that part of your abstract. Feel free to discuss it on our ML if you like:-)

is this supposed to be useful? amp

[Anonymous Coward]

rotating windows? why? how does this help me interface with my computer?

transparency? all the implimentations of this i've ever seen required you to hold control or alt or something to select the window behind the transparent object making it a huge pain in the ass to negotiate.

why bother?

Re:is this supposed to be useful? amp

[t_hunger]

Very simple reason: When you use a graphic program, then you do expect to be able to rotate graphics, don't you? So we had to program rotateble graphics. No way around that. In fact we'd have to write some code to stop people from being able to rotate windows! What a waste of time;-)

A Window is a graphic in Fresco. So you can rotate them. Nobody really played with such an idea yet, so I don't know wether it improves useability or not. Somebody suggested to move 'dangerous' operations like 'close window' etc. onto the backside of a window and display some information there (PID, a CPU usage graph, things like that). With Fresco you got the chance to try that...

Finally in a 3D walkin environement you need to be able to display windows in all kinds of ways as you can walk around them. Fresco is capable of running in such an environment (in theory, ran once in a CAVE IIRC but crashed due to buggy libraries;-).

CTWT

[kentyman]

I propose a new geek acronym, usually applied to open source projects...

CTWT: 'Cause They Want To.

Can be changed to work better in first person...

CIWT: 'Cause I Want To.

Maybe I'll try it on my girlfriend next time she "has a headache."

-kentyman

Re:CTWT

[Anonymous Coward]

A "headache?" DUMP HER ASS!

Any other Fresco themes besides Motif?

[truth_revealed]

That Motif look is really quite dated. Does Fresco offer other themes?

Re:Any other Fresco themes besides Motif?

[Anonymous Coward]

it offers WidgetKits which do exactly that - but graphical design is something we currently avoid, rather straighten out the API first

of course you're free to build a better looking one :)

wohhoo

[Anonymous Coward]

I'll pretend it doesnt look like shit and have pointless features and say...

oh fuck it that crap fucking blows.

Re:Maybe in 10 years-- no look at their pages

[bluFox]

far from it ,, these people have achieved some some success in their ideas,

I hope it is can be the replacement to X that most of us have been waiting for,

for benifit of people not familiar with fresco:

they have moved the window manager and the toolkit portion to server thus achieving (hopefully) consistant look and feel , they use corba heavily and i guess it has some replacement of X protocol , but i have not been able to find from their site.

It's been a long time...

[jregel]

I have watched the Berlin project for several years, remembering the initial idea to create a graphical system written in Assembler, a change of project leaders and the decision to use CORBA.

I don't think that Fresco will replace X anytime soon, if ever, but it's an interesting technology demo that will surely influence other projects. Playing around with the Quartz technology in MacOS X has convinced me that better and more interesting ways of doing graphics are possible - the Fresco project, by using device independent rendering (OpenGL / Postscript) and an ORB merges some of the advantages of X and DPS / Display PDF.

Why Berlin is now called Fresco

[Jeremy Erwin]

Fresco consists of a number of interlocking projects, each named after an city (Berlin, Warsaw, Prague, Babylon). The "Berlin" program was the window server, as well as the entire project. To avoid confusion, the project name was changed to "Fresco". The window server is still called "Berlin".

Its kinda funny...

[Anonymous Coward]

I just think its a little funny to see the leaked Longhorn screenshots from a few stories down, and then to see the Fresco screenshots.

.sig

[kentyman]

I just wanted to say I like your .sig.

Regards,
kentyman
Regards
-kentyman
Regards:
kentyman
Regards, kentyman

Re:.sig

[Anonymous Coward]

Very nice.

Re:Maybe in 10 years-- no look at their pages

[Anonymous Coward]

fresco has its own network protocol, which consists simply of calling object methods over CORBA.

using a polling mechanism to detect disconnects it had about 2kbps of line traffic when we measured it in june on linuxtag when doing normal operation (scrolling, moving, clicking, ...). creating objects takes a bit more, thus giving small peaks when starting applications

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 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?

Re:Getting higher speeds out of Linux graphics

[nathanh]

But where's good documentation for DGA? Is there anything faster than DGA in X?

Depends on what you're doing. DGA gives you direct access to the framebuffer. This means you miss out on potential hardware speedups (line renderers, rectangle fillers, bit blitters, etc) which are increasingly common in modern GPUs. But if you just want to flip bits in the framebuffer then DGA is as good as it gets.

Other extensions that might help you improve the speed of your application - dependant on what you're doing, of course - include XVideo, XRender and DRI. The DRI has the greatest potential (no queue, no encoding, no decoding, no buffer copying, no context switch) but DRI has only been implemented for GLX so far.

The documentation problem you mention is very real. Part of the problem is that very few people know the extensions well enough to document them. Those people who do know the extensions well are VERY busy improving XFree. However, if you know about MIT-SHM, DGA, XVideo, XRender and DRI then you know all of the relevant extensions already.

Re:Getting higher speeds out of Linux graphics

[FeatureBug]

"Those people who do know the extensions well are VERY busy improving XFree."

The MITSHM documentation was written by Jonathan Corbet (of Linux Weekly News?) and Keith Packard in 1991. That's over 11 years ago! Is there a lack of good documentation because people are really too busy to write the documentation or is it because they do not want to write documentation?

Re:Getting higher speeds out of Linux graphics

[nathanh]

The MITSHM documentation [reptiles.org] was written by Jonathan Corbet (of Linux Weekly News?) and Keith Packard in 1991. That's over 11 years ago! Is there a lack of good documentation because people are really too busy to write the documentation or is it because they do not want to write documentation?

Well, MITSHM is over 11 years old and there's little value in writing new instructions for MITSHM because there's nothing new to add. Some of the newer extensions have good documentation (eg, XRender).

But whether individual developers don't write documentation because they don't have time or simply don't want to is something I can't answer. I daresay it's a bit of both.

Re:Getting higher speeds out of Linux graphics

[FeatureBug]

My point is documentation about speedups in X is often missing, incomplete or lacks detail.

MITSHM is probably the most important speedup method for X applications because it is actually fully implemented across all graphics cards (unlike XRender whose implementation is apparently incomplete according to the website) but despite MITSHM being over 11 years old it still lacks complete documentation. Its adoption is being held back by poor documentation. I know XFree86 is mostly undertaken by volunteer programmers, but X and some of its extensions like MITSHM itself wasn't developed in that way. MITSHM was written by people who were paid to write the code. I just wish they had been required to write complete documentation.

Re: 'fresco' means 'fresh'

[Anonymous Coward]

>> Fresco is actually an Italian word for painting.

More specifically, fresco is a style of painting on plaster which is often used for murals. They are painted "al fresco," or colloquially "out in the open air."

"Fresco" literally means "fresh" and idiomatically means "cool." Let's hope the project lives up to both!

Does Corba have to be Slow?

[pavon]

It seems to me that alot of people are complaining about corba being slow, and I have to wonder if this is necicarry because of inherent difficulties in the specification of corba, or just due to the current implementations. I know for a fact that object oriented message passing does not have to be slow. Case in point: the Cplant project at Sandia Labs, which aims to have a linux cluster as fast as any of the ASCI machines has a message passing protocol which is moved into the kernal (along with pipes, sockets and other IPC) which is blazingly fast.

Re:Does Corba have to be Slow?

[t_hunger]

CORBA could be faster I guess. For one thing it encodes everything it sends out over the wire as text messages... nice to debug but not really mashine friendly. Then CORBA does a lot more then simply passing a message. It handles all those nasty details you have to keep an eye on in a distributed, heterogenious world. It would definitly be a lot simpler if it could just assume all mashines to have the same character encoding, endianess, ... like Cplant obviously can.

Fortunately CORBA can leave out a lot of the overhead in the 'local case' when communicationg with objects on the same mashine or even in the same address space.

Re:Does Corba have to be Slow?

[Anonymous Coward]

CORBA's 'IIOP' protocol is needlessly complicated - it mandates type padding and different machine byte orders, to name a couple of problems. If you only use the same ORB you avoid these specific issues. You can have a CORBA calls actually be a direct call but you still have to wrap all your data in those silly var and sequence wrappers and that wastes local CPU time. So, to answer your question - local CORBA is slow and awkward to program in by design due to its 1985-style type memory management. There is talk every 6 months about the C++ CORBA API being so awkward to use and someone always pledging to rewrite it to be more normal, as in using STL vectors instead of sequences and std::string instead of the crude CORBA strings, but these "initiatives" always die off when people realize that it's a waste of time trying to put lipstick on the CORBA pig.

Are these the same idiots?

[Anonymous Coward]

Are these the same idiots from two articles ago complaining that computers are to fast to be useful and all the extra power is a waste.

But then now they say X is to slow and needs to be reinvented like so many wheels?

Hello? what is it? If X is to slow on your crusty old hardware then MAYBE YOU SHOULD UPGRADE?

How can you say a 2 GHz CPU IS TO FAST and then 30 minutes later bitch that SOFTWARE IS TO SLOW!

When will Xrender be completed?

[HanzoSan]

I bet Fresco will be finished before Xrender has image transformations, true hardware alpha channel, etc.

X is just now getting anti alaised fonts and everyone is saying X is so great, we are about a year away from the release of Xfree5.0 which is supposed to have the finished Xrender, only one guy is working on Xrender (Keith Packard)
The founder of the X project Mr. Dawes claims they are just now beginning to focus on

Quotes from David Dawes David Dawes: There has been some work on a new rendering model for XFree86 that provides some more advance composition techniques (including transparency), this currently being implemented in software. For XFree86 5.0 we'll be investigating this as part of our review of rendering models, and seeing if a hardware implementation would not be more appropriate.

Currently Xrender is still in the planning stages, its at about the same level as Fresco, not really useable to anyone but perhaps Keith Packard and a select few developers, its unfinished, its beta but to users and not so skilled programmers its vaporware.

I'm looking towards XFree86 5.0, which will be the next significant step in XFree86. We're only just starting to think seriously about it. We'll start by re-evaluating what we would like from a graphics/windowing system, and not limit ourselves to the ones that currently exist. With XFree86 4.0 our main focus was on the device-dependent component of the X server (DDX), and to do that we needed to provide a more modular infrastructure. The features that came out of that process showed how much it was needed, and it has given us a solid DDX base from which to expand into other areas. For 5.0 I expect that we'll move more into the device-independent (DIX) and protocol areas as well as making some adjustments to the DDX area based on our experiences with 4.x.

Ok so for Xfree86 5.0 they will focus on improving the rendering, and bringing X to the levels of Aqua, but by the time 5.0 gets here expect Longhorn to be released, and expect OS 11 to be released by Apple which takes things to the next level.

Linux needs to do more than just keep afloat and compete, Linux has to dominate to beat Microsoft.

Currently the only thing preventing Linux from taking the desktop market, is the fact that the currently Linux interface doesnt look polished enough, theres enough programs for grandma, theres games, theres plenty of office apps, the casual user can use Linux, the only reason they wont use Linux is because OSX is better than Linux.

Why buy a Linux dell laptop for college when you can get an Ibook thats just as powerful but better?

Why get Linux if its just like Windows? This is why Windows users would sooner switch to Mac.

X is now one of Linux's biggest bottlenecks, along with the fact that they have no music apps and not enough file sharing apps.

Re:When will Xrender be completed?

[Anonymous Coward]

Becuase a GNU/Linux system is Free Software not owned by Apple MegaCorp.

Re:When will Xrender be completed?

[Anonymous Coward]

one of Linux's biggest bottlenecks [is] not enough file sharing apps

Last time I looked, all of the major file sharing protocols were supported by some Linux app; there are, embarringly enough, a lot of warez kids in to Linux because they confuse the ideals of the GPL with the ideals of the warezers.

I assure you that the kind of warezers who spend all day downloading pirated software, music, and movies are not the kind of people who make a real difference in terms of mainstream popularity.

X is a problem. Lack of music apps is a problem. Lack of warezing apps is not a problem.

Re:When will Xrender be completed?

[RustyTaco]

Linux has to dominate to beat Microsoft.

WTF would care about Microsoft, they blow hard. If you want to talk about playing catch-up go look at quartz exteme, though you'll probably want a new G4 first.

Currently the only thing preventing Linux from taking the desktop market, is the fact that the currently Linux interface doesnt look polished enough,

You have at least seen screenshots for KDE3 havn't you? It looks much better than XP, and tends to behave more consistantly. Again you're barking up the wrong tree.

Why buy a Linux dell laptop for college when you can get an Ibook thats just as powerful but better?

I can't think of a reason. iBooks kick ass as a Linux laptop. Next to OSX E+Gnome or KDE seem lightning fast, I still run fluxbox though. You get WORKING sleep support too. I have to laugh every time I a a PC user with a Dell, etc, shutdown his laptop before he leaves, or boot it up before he can use it. My iBook stays up for weeks at a time, mostly sleeping, and is ready to use in a few seconds(

X is now one of Linux's biggest bottlenecks, along with the fact that they have no music apps

What is a "music app" I must ask? I'd imagine it to be something that plays music. I'm sure I have half a dozen installed, though I usually only use XMMS.

and not enough file sharing apps.

Well of course, because no computer could posibly be useful unless you're committing a felony with it. Uh-huh.

- RustyTaco

Re:When will Xrender be completed?

[curious.corn]

But you don't expect people to buy an old school skoda when even the current ones are franchised WW Golf just one generation behind, don't you?
I'm a Linux zealot but I drool for OsX and even consider raping the wallet for it so I consider myself unbiased.
I don't expect people chew on X only because it can do remote display when even the gurus don't use it and stick to VNC or ssh. I myself was happy to tears when XFree 4.0 was released: goodbye damn Modelines and enough late too!
Competition is good and I wish Fresco success, just as much as I do for amd vs intel, or us and apple against m$.
I wanna live to see photoshop on qt and if this project will help somehow I praise it (don't mind the Free/Non Free stuff for now, when the big commercial desktop sw will start knoking @ our door I'll beleive we will have won)

Re:When will Xrender be completed?

[sql*kitten]

I bet Fresco will be finished before Xrender has image transformations, true hardware alpha channel, etc.

Why bother with XRender when there's the proven GLX?

Re:When will Xrender be completed?

[Anonymous Coward]

Currently Xrender is still in the planning stages

The RENDER protocol is finished. The client libs are done (with a few features missing, such as support for gzipped fonts). There's nothing preventing you from using RENDER in your application right now.

before Xrender has...true hardware alpha channel

Just to be clear: compositing is supported in the current version, it just isn't accelerated. Note that it wasn't accelerated in MacOS X until 10.2, and the system was more than usable.

Accelerated compositing is being worked on, and will doubtless be implemented for selected drivers in the XFree86 4 series. The XFree86 folks want to get some implementation experience before they commit to an acceleration framework for compositing, and that is what is only planned for XFree86 5.

Re:When will Xrender be completed?

[IamTheRealMike]

X is just now getting anti alaised fonts and everyone is saying X is so great, we are about a year away from the release of Xfree5.0 which is supposed to have the finished Xrender, only one guy is working on Xrender (Keith Packard)

RENDER is basically done. What you're thinking of is, we don't have true transparency yet. Well what do you know, that's because

a) Transparency is useless for virtually anything except screenshots, making a list of places where it enhances usability for instance is very hard.... and

b) X has bigger issues which need resolving first, like on the fly resolution switching (R&R, done), decent cursors (XCursor, done), reducing the amount of configuration work needed (ongoing, the aim is to eliminate the XF86Config file eventually).

And FYI the Matrox drivers already have hardware accelerated alpha blending.

People make such a big deal of having "true" transparency, but you know what? I'd probably turn most of it off. Truly transparent terminal windows I find are harder to use than the desktop wallpaper transparency that KDE and GNOME use. One shows you all the text, lines etc, the latter just gives you a nice working background. Maybe if they were blended as well to make the background less distracting, that'd be cool, but at the end of the day it's just FUN, not USEFUL.

Re:When will Xrender be completed?

[QuietRiot]

X is now one of Linux's biggest bottlenecks, along with the fact that they have no music apps

What is a "music app" I must ask? I'd imagine it to be something that plays music. I'm sure I have half a dozen installed, though I usually only use XMMS.

You'd imagine wrong. The original author probably ment music creation apps. This is often a big gripe among free-software naysayers. He's wrong, as there is stuff out there - just not the products he's comfortable with, most likely those only availible on Windows or Mac platforms.

Re:When will Xrender be completed?

[HanzoSan]

Please tell me why KDE, Gnome, Enlightenment(in fact rasterman himself told me it wasnt possible) cannot do alpha channel, and genie like effects, please explain why theres no realtime shadows on my windows, why is there no realtime scaling?

Please tell me if Xrender is completely finished, why is it not being used by anyone?

If its so finished perhaps its too hard to use so no ones using it, the only people who seem to be able to use it are keith packard and Xfree developer types.

Re:When will Xrender be completed?

[sl3xd]

Honest query: I've thought of this myself, and wonder what problems there may be to implementing a UI toolkit (such as GTK or QT) so that it uses GLX to render the widgets, rather than the current method. (Since making a window using GLX is fairly close to a no-brainer; but how to take an app like GIMP or Konq and putting the entire app onto the GLX extension is a mystry to me...)

Re:When will Xrender be completed?

[shellbeach]

Currently the only thing preventing Linux from taking the desktop market, is the fact that the currently Linux interface doesnt look polished enough, theres enough programs for grandma, theres games, theres plenty of office apps, the casual user can use Linux, the only reason they wont use Linux is because OSX is better than Linux.

Ummm ... as far as I can see, the main reason behind the small market share of Linux is the fact that Windows is almost exclusively installed on new computers and it's also what people use at work. Who wants to use Linux if they feel comfortable using Windows? The thing is, most people barely feel comfortable using Windows and the last thing they want is to have to learn a whole new system, new apps, and be forced to cope with kernel messages scrolling by at start up.

If linux ever does grab more than 1% of the desktop market, it will be if - and only if - it gains acceptance in the workplace and people have to use it at work. X has nothing to do with it - think Windows 3.11 if you don't believe me! MacOS was streets ahead when Win 3.11 was released in terms of being "polished", but that didn't make people use the Mac, did it? Seriously, if you think Fresco or XFree86 5.0 will magically turn Linux into the OS of choice for Joe Average, I think you'll be highly disappointed.

Personally, I use linux exclusively at home and am highly anti-Microsoft, but that doesn't stop me recognising how much happier most people are with Windows. You've just got to accept that it's highly likely that linux will never achieve "world domination" ... and it's probably a good thing that it won't.

Re:When will Xrender be completed?

[Anonymous Coward]

a) Transparency is useless for virtually anything except screenshots, making a list of places where it enhances usability for instance is very hard.... and

we don't really know how useful transparency could be because no system really has it (IFAIK). but i think transparency could be useful if done correctly. it really belongs in the window manager. the user should have control over the level of transparency for each window. this would allow you to work in windows that are partially covered or reference covered windows while working in another. another idea would be for unfocused windows to become transparent while the focused window is solid. windows could become transparent when being dragged, giving a bit more visual feedback since you could see what is underneath when placing the window. what we have now, with terminal windows showing only the desktop background (not other windows) is really just eye candy. but if we had true transparency i think it could be very useful and make for a nice environment.

Re:When will Xrender be completed?

[HanzoSan]

First is GLX powerful enough? Second if its so easy why havent they ported it? GTK is being ported to Directfb.

Re:When will Xrender be completed?

[zapfie]

Transparency is excellent for shadow effects, which are very useful indeed. Cursor shadow help the user keep track of the cursor, window shadows can provide clues to the user about which window is in focus, and provide a sense of depth to both windows (including things like menus) and widgets, so it does not seem like they are sheets of paper laying flat on eachother. Yes, it is not necessary per se, but they are good visual cues, and not just for 'fun'.

Re:When will Xrender be completed?

[Anonymous Coward]

Everytime someone turns on font antialiasing in KDE or GNOME(2), Xrender is used. For every damn letter on your screen. I know my desktop is antialiased. Has been for a LONG time now - Mandrake 8.0, I think, is where Mandrake started configuring the antialiasing stuff into their X build.

Anyway, I see from your posting history you're just a troll. But you're spreading disinformation, which is annoying.

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:For God's sake

[Anonymous Coward]

Everyone is saying,

No, I think what everyone is saying is:
1. Eat banana
2. Visit www.thehun.net
3. Imagine what you'd do if you had a girl like that
4. Think dirty and masturbate
5. ??
6. Profit.

Re:For God's sake

[donscarletti]

You are saying:
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.

And you don't realise your answers are flawed
1. Why not? I'll tell you why not, the average open source desktop is rough and burred around the edges, it is immature and majorly buggy. X is a small part of the desktop that is not quite as bad as gnome, kde etc. as it is older and therefore more refined. Fresco is unpolished and raw. That is exactly what we don't want. And we don't want to recode every single graphical app either.
2. You suggest reading the page. What I read on the page is that they concede that CORBA is slightly slower than X proticol and also they make no claim that it will perform any better with multiple windows open etc. They concede that X has real-world measurment support and make the feeble claim that it is simply being ignored. Instead they simply beleive that in their project measurements will not be ignored although in all probibility people will still use pixels and bitmaps and all the other evil unscalable nasty things. To me this assumption of theirs seems completly unfounded. The X compatibility will be discussed later.
3. It's not done indeed. And it wont be done for absolutely ages. Therefore in eight or nine years when it is usable the Open Source desktop community will have a couple of choices. 1 rewrite every graphical program ever done (which would number much heigher once fresco is finished). 2 use X compatibility and therefore entrust their graphical performance to a stopgap layer of twisted emulation and also invalidate pretty much every new inervation in the entire system. 3 port GTK+, QT, TCL and every other widget toolkit to fresco meaning that full native porting is easy but the entire notion of desktop consistancy goes streight out the window. or 4 forget about fresco and just keep on using X. To me 1 seems time consuming, counterproductive, 2 seems pointless, 3 seems to undermine half of the point of fresco and 4 seems to be the most likely option, sorry.

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

Frankly rival projects are what got GNU/LINUX into trouble in the first place. Twice as much coding is needed for the same result or alternativly the same amount of coding half as much results. Rival projects is why the OSS desktop is inconsistant. Rival projects is why copy and paste are shoddy. Have you noticed that the gimp is unrivaled in its field and it happens to be one of the only graphical applications that is up to the standard of its commertial rivals.

This is not like CERN and Fermilab or Ford and GM or Pepsi and Coke, this is a break in methods of communication. This is isolation of projects and being such an integral part of the pc environment will effect communication throughout all graphical applications. This will mean that not only graphical server development will be split but every application too (unless you want to rely on shoddy emulation layer).

It makes me cringe with the irony that a project that seeks to make the desktop more consistant is makeing it even more inconsistant. Frankly though it just makes me sad.

Re:For God's sake

[t_hunger]

1. Why not? I'll tell you why not, the average open source desktop is rough and burred around the edges, it is immature and majorly buggy. X is a small part of the desktop that is not quite as bad as gnome, kde etc. as it is older and therefore more refined. Fresco is unpolished and raw. That is exactly what we don't want. And we don't want to recode every single graphical app either.

I don't consider Fresco to be raw around the edges. The ideas were around for a long time now, the architecture is definitly more refined then any other windowing-system's I've seen so far. And I looked into a lot, both before I started to work on Fresco and after.

[...]They concede that X has real-world measurment support and make the feeble claim that it is simply being ignored. Instead they simply beleive that in their project measurements will not be ignored although in all probibility people will still use pixels and bitmaps and all the other evil unscalable nasty things. To me this assumption of theirs seems completly unfounded. The X compatibility will be discussed later.

Very simple: There are no pixels in Fresco. You can of course display a image, but only if you specify a resolution for it. It will be scaled to have the right size on the monitor.

The compatibility issue is discussed in detail in out FAQ which I am sure you have read. Too lazy to duplicate it here. I further don't feel like discussing your idea of choice being bad.

Amiga people..

[Anonymous Coward]

will love this! There are some similarities.. I will try to write demos to this WM! This feels as cool as Amiga OS back in the old days.

Re:Amiga people..

[t_hunger]

You are very welcome to do so. I just hope you do use WM in a amiga-ish kind of way and don't think Fresco is a WindowManager;-)

You love X?

[Anonymous Coward]

freak

Editors, PLEASE add value here

[sacrilicious]

It would be nice if the slashdot editors would ensure that the slashdot blurbs convey - even generally - what a given project is about. From the slashdot blurb on this, I have no way of telling what "Fresco" is without reading the article. I'm supposing it's a software product (though it might be hardware). I have little idea whether it's a lightweight linux distro, a financial planning application, or a virtual porn site. I don't know if it's free or commercial. I *could* click the article and read it to find out. But I won't, because I'm not that intrigued by a product that I have no knowledge of; there are tons of those.

.

Re:What's the point?

[Anonymous Coward]

You're right; they should all be like you and spend their time posting inane comments to slashdot instead. Obviously, that's much more useful.

"Only thing preventing Linux"

[kentyman]

Currently the only thing preventing Linux from taking the desktop market, is the fact that the currently Linux interface doesnt look polished enough, theres enough programs for grandma, theres games, theres plenty of office apps, the casual user can use Linux, the only reason they wont use Linux is because OSX is better than Linux.

The problem is, there are caveats to all of your statements.

IMHO, KDE3 with some of the themes they have look much better than Windows and OS X, the plenty of programs for grandma aren't as easy to use, there are games but not many, there are plenty of office apps but none can replace Office 'cause of compatability, and the casual user can use Linux until a problem comes up and then they are farked.

Why? 'Cause casual users can't use the command-line well, and if there is for example a driver problem in Linux you don't just download the latest driver installer. No, there are thinks like dealing with kernel modules, symlinks, and worse of all, READMEs.

Sure, any of these users could get figure it all out eventually and get good at it, but people are lazy.

Only think preventing Linux: people are lazy.

A good read...

[Anonymous Coward]

and the mods marked this troll? more like offtopic please!

You've missed the point.

[Lethyos]

When you're developing software, having "transparent spinny" thingies is part of testing what you're trying to accomplish. But you probably wouldn't realize that.

The point of Fresco is very similar to the point of Quartz on MacOS X. It's a composited windowing system that doesn't "fake" sophisticated rendering like X currently does. Translucent windows now work by taking a "screenshot" of the area occluded by the window, then adding the color values together. This is a hack. A composited render draws things from back to front, taking into account a Z axis position and the alpha bits in a color block (RGBA) (this is fairly layman, but gets my point across).

I don't know why you're considered insightful for this, but rest-assured, we need a project like Fresco to develop a better windowing system. In the future, computer displays aren't going to be treated as fixed-pixel dimentions with static elements. A computer screen will be like a piece of paper. Elements will be drawn by real-world measurements (x centimeters versus x pixels) such that the number of "dots" will become arbitrary. Things will have to rotate freely. Alpha-blending will be absolutely necessary for proper hinting. And so on and so forth.

X11 is great, but very arcaic. It must go away in the future. Apple's got a good lead -- and pretty soon Microsoft will duplicate their efforts. We've got to be in that game too.

Re:You've missed the point.

[AJWM]

A computer screen will be like a piece of paper. Elements will be drawn by real-world measurements (x centimeters versus x pixels) such that the number of "dots" will become arbitrary.

Ohh...

You mean like Display PostScript - circa late 1980s, or NeWS, which predates even that.

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:bla

[Anonymous Coward]

that should be "blah" not bla or pla. what the heck is pla? u incompetent fool. score -1 indeed.

X is not slow.

[anonymous coword]

And this thing is crap, i havent downloaded it yet but it looks like 'rotating windows' is its only technical merit.

Re:X is not slow.

[Anonymous Coward]

Fresco's technical merit is in its design, as documented in the book Design Patterns.
The interfaces are all well-defined as CORBA IDL files. You should read them. First thing you should understand is how to compose Graphics. Fresco is to TeX what Mozilla is to CSS. HBoxes (which are Graphics) are filled with Graphics, and the LayoutKit has the smarts to do the layout appropriately, including alignment. Very fancy stuff. Window placement, orientation, zooming are all handled by a stack of 4x4 matrices so the demos of rotated windows falls pretty naturally out of the design.

Bottom line is, just because you don't know how Fresco works, don't claim that rotating windows is its only technical merit. That's like saying that ability to count is a computers only technical merit.

Re:X is not slow.

[Anonymous Coward]

In other words, you either don't understand the project documentation because you are an idiot, OR you simply didn't read the project documentation and judged it by the screenshots alone, because you are an idiot.

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:deeper issues

[curious.corn]

You end up with an awful and awkward looking experience just for this "feature" which actually isnt all that important.
Just as sub pixel AA aka cleartype you love so much, rinse the m$ propaganda off and reconsider. This stuff really gives you headaches: the sides of a font have different tints, everything looks like your monitor blew a fuse and no pro graphic will ever have this crap interfere with the color calibration system. Need better edges? Buy a 1600x1200 monitor and stop whining; the fonts are ant like? Increase size; the GUI is screwed Redmond hardcoded the widget sizes? I pity you. BTW, OsX is all about vector based formats from the truetype fonts - oh, but your rest of the computing world doesn't use them - to svg resizable icons and widgets (where the difference between pathetic winblast theming progs and the original really shines)
I hate to be hard but... are you shure you're a nerd?

Re:deeper issues

[Anonymous Coward]

OSX is indeed vector based in its description language, but you will find people map the Vector corordinate system to be 1:1 with the pixels.

This is why a 200x200 pixel image in a webpage will take up exactly 200x200 pixels on your monitor.

Duh.

Re:deeper issues

[be-fan]

Amen to that. I run a 1600x1200 15" LCD screen, and KDE doesn't give me a single bit of trouble with it. Everything looks exactly like it should, only sharper. Well designed web pages look just as great. In comparison, Windows just doesn't handle it as well. It certainly doesn't look bad, but you can definately notice that you're using larger than normal fonts because of layout glitches.

Re:My only question is...

[Captain Zion]

In Brazilian portuguese, it's a slang term for "sissy" or "effeminate". The original meaning is "fresh", like in "fresh air".

This page contains an excerpt from Beyond Carnival by James N. Green and tells more about the term. I won't reproduce the text here, or I'll be sent to the Camp of Tolerance. (Hail Lemmiwinks the Gerbil King!)

3D/OpenGL support? (PicoGUI?)

[Anonymous Coward]

Does anyone know how things like Fresco and/or PicoGUI perform when doing 3D stuff?

I mean, would it be possible to do Quake3 and get the same or better framerate as you get in X?

I'm not specifically interested in games, I just thought that was a good example of something high performance. Something more real world would be a CAD or 3D modeller application? How would something like that perform in Fresco or PicoGUI (versus X or Windows)? Anyone know?

Seems like there would be too much overhead because of the client/server connection. Is OpenGL separated somehow, or is the client/server connection super fast? Would it be possible to do remote 3D stuff?

Thanks for any information!

Re:3D/OpenGL support? (PicoGUI?)

[Anonymous Coward]

Haha, you been ignored!

I don't know either, but I'd like to know.

Maybe the Fresco author(s) don't feel it's necessary to promote their software and moderators think you suck.

Re:3D/OpenGL support? (PicoGUI?)

[t_hunger]

We don't consider games. Those usually run fullscreen, so why should they bother to use Fresco in the first place? Any windowing system is unneeded overhead for things like that.

CAD and 3D modeller are up another alley:-) Such applications usually manage a scenegraph describing the objects and their relations to each other. That maps wonderfully to Fresco: That uses a scenegraph too. So far we have only very simple demos showing very simple meshes. We could need some help polishing this of a bit.

Performance should be similar to X or window's performance of those applications inside their window. The difference is of course, that with fresco 3D is 'liberated from simple 2D windows'.

This should work over the network. All objects are stored inside the server, so only very little information needs to go over the wire once the object is set up. The server can use whichever graphic acceleration build into the hardware it runs on, independent of wether the client runs locally or connects over the network.

Canada

[kentyman]

So what are we going to name our new country?
<Canuck_2> I have an idea! We'll put a bunch of letters in this hat and draw them at random.
<Canuck_1> Brilliant! That's aboot the smartest thing I've ever heard.
<Canuck_2> Let us begin...
<Canuck_1> C, eh?
<Canuck_1> N, eh?
<Canuck_1> D, eh?

minix is parent ? i doubt it!!

[bluFox]

Tanenbaum-Torvalds Debate

chances are that Tanenbaum wont let minix claim the parenthood of linux, nor would linus want it,,,

Re:An intro that actually introduces would be help

[Anonymous Coward]

yes, especially since the name is so similar to Freesco.

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!

wow

[Anonymous Coward]

now you too can run ugly-ass motif applications
in a virtual window

microsoft wins .. i hate microsoft, but even i
can tell they win - if the big news in the *nix
community is another rehash of a window manager,
there is no hope. this is why open source fails.
may rms choke on his own vomit.

Re:The Tao of Linux

[Anonymous Coward]

excellent work!! i am enlightened!

Berlin - Fresco name change

[Steve Hamlin]

See THIS LINK in the story.

Comparison to PicoGUI?

[Ian Bicking]

PicoGUI, discussed here recently, 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? 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:Comparison to PicoGUI?

[nutshell42]

Why not have a look at the FAQ on the PicoGUI homepage:

Fresco is another GUI (http://fresco.org) that has some similarities to PicoGUI. Fresco has been around for quite a while longer than PicoGUI, but when PicoGUI was started MicahDowty didn't know about Fresco.

Similarities between PicoGUI and Fresco:

-Standard widgets on the server side
-Separation between applications and device coordinates
-Server keeps a scene graph
-New GUI architecture, with no backward compatibility
-Language-independent client/server protocol

Differences between PicoGUI and Fresco:

-PicoGUI takes a lot of shortcuts compared to Fresco, to make it more suitable for embedded systems
-Fresco uses device independent coordinates everywhere, while PicoGUI's themes and layout engine still use pixels
-Fresco uses CORBA, while PicoGUI has its own network protocol
-There's nothing like PicoGUI's theme interpreter in Fresco
-Fresco handles overlapping, and uses a homogeneous scene graph making it more suitable for generic drawing apps and desktop window management
-PicoGUI has features taylored for embedded systems, such as support for low-end display hardware, and keyboard-only navigation
-Fresco does real transparency, while PicoGUI usually cheats :)
-Fresco relies heavily on floating point math, PicoGUI's core is 100% integer. Of course this means that picogui's layout engine has to operate in integer pixel units. (See below)

Of course they have more in common - both are seen as traitors and main enemy by all the X zealots who come out of their holes every time there's an article about (perhaps) better replacements on /.

Re:Comparison to PicoGUI?

[IamTheRealMike]

PicoGUI is somewhat less ambitious than Fresco.

For instance, fresco has subpixel addressing, a scene graph based windowing model etc. These aren't buzzwords, but I can't really explain them all in depth, i'm too tired right now.

Fresco is based on corba which is implicitly multilanguage, so that's not just picogui.

NeWS was an early attempt but it had design issues and never really went anywhere.

Yeah, I'll second the last comment. It's good to see people trying out new ideas. I suspect that soon X will have most of the features people want in the short term, and we'll all be happy, but that doesn't mean X is perfect and cannot be improved upon. It's good to know people are thinking about a future beyond "we want transparency".

Re:Comparison to PicoGUI?

[Ian Bicking]

I don't really think it's fair to say PicoGUI is less ambitious -- after all, Fresco is not attempting to handle low-end devices, and it is not dealing with novel interfaces (as necessitated by small devices). For instance, PicoGUI uses predominantly tiled spaces, as opposed to overlapping windows; I personally consider this vastly superior for 99% of application use (BTW, I'm using Ion on X). It's a sort of less-is-more. I don't think pragmatism should be confused for unambitious.

As far as NeWS, it went further than either Fresco or PicoGUI has gone so far (in terms of functionality and practicality). It was truly novel -- I really think it deserves serious thought from any wannabe-X-redesigner, both for its successes and failures. As is often the case, many of the most important choices are made early on, and many of the most important alternatives are forseen by those involved. Of course, the best choices are not always made, we all know what some of the shortcomings of X are, and some of the outright failures of the original vision. But there were important ideas on all sides.

Re:Comparison to PicoGUI?

[t_hunger]

There's a list of GUI-related projects I find very inspiring on Fresco's link page under Other GUI Projetcs. I hope we can get all the good things from all those systems together into Fresco... of course since they vary widely wrt. the scope and ideas behind each project that will not really be possible. But all of them have some very nice ideas and deserve to get some attention from anyone wanting to design a new GUI system (or improve an existing one) IMHO.

Also make sure to check out the "Important external Link" Sections for such interessting things like Squeak and more:-)

Do you have a link to more informations on NeWS (or other projects as interessting as that)? The one in said list does not really give that much information...

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

Re:none

[be-fan]

Um, who would these "open source guys" be? The software I write is open sourced. Does that make me an "open source guy"? Do you think I give a fuck what *you* think Linux needs to compete with Windows? Do you think these Berlin guys do either (though, they'd probably phrase it more diplomatically!) They're working on this because they enjoy it. They're not employees of some Open Source Corporation that have product deadlines and focus groups and such shit.

PS> As for software installation, you're using the wrong distro. Software installation for me is a two second (literally) process where I type "emerge " Same thing for Debian users. Silly Windows users spend precious minutes scouring around the net, downloading a program, navigating to the installer, and clicking 'next' a bazillion times before the program is installed!

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.

They are following Interviews

[Anonymous Coward]

Hope they don't follow interviews to the grave.
Interviews went down the toilet because of a massive failure to document among other problems.
Interviews was an interesting project maybe 7 or 8 years ago, when I tried to use it in grad school. The operative word was tried because all the documentation was in C++. Then Fresco spun off and it languished. Good to hear that they tried to do some stuff, but I just don't see anything compelling about it. Unless they capture a high quality interactive part of the developer community and make a compelling case, they lost. We've got KDE which has QT and GTK for Gnome. Their best bet is to make a superior interface for those. If they can plug the memory leak I experience in all my Linux X servers, I'd be delighted (I hate closing down my interface every week or so because X needs 100 or so more MB more).

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?"

Well...

[autopr0n]

I think anyone reading slashdot for the past few years would know what berlin was.

Of course, since slashdot has gone down in quality so much most of the people from long ago are gone (actualy the comments have been getting a little better lately, but the stories are still crappy as hell)

Wow, it's pretty ugly.

[autopr0n]

Damn, what a fugly widget set. Hopefully they'll get something better soon.

How extensible is the API that these people are using, as far as the ability to theme the widgets/windows/etc?

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.

But it's not irrelevant.

[mindstrm]

It's a developer issue.
IT's still too difficult for developers to know what toolkit to use to write applications for Linux... especially if they wan't something modern.

Yes, they can use GTK. Yes they can use QT.
What version should they pick? What will be the most compatable?

It would be nice to have a NEW display API that really rocks... that's what this is about.

Re:Blah

[0x0d0a]

Linux on a 286...won't even BOOT

That's not true. There's a backport of Linux to the 286 (I believe the big technical issue was no MMU...).

Kde3 better than OSX? What are you smoking?

[HanzoSan]

KDE doesnt do alpha channel properly, it cannot do realtime shadows yet, it cannot do image transformations such as genie effect, it cannot do realtime scaling, it doesnt fully anti alias everything on screen, it doesnt use your video card to do this in hardware if you do find some software hacks to do this, so X is extremely slow.

KDE better than OSX? hell no, check back in 2-3 years and maybe you'll be right.

Re:Kde3 better than OSX? What are you smoking?

[be-fan]

it cannot do image transformations such as genie effect
>>>>>>>>
Not to windows it can't, but it can do them inside windows, which is far more important.

it cannot do realtime scaling
>>>>>
What's that? If you mean scaling the graphics because the drawing API is vector based, nothing else can either. If you didn't notice, most OS X widgets are bitmaps.

it doesnt fully anti alias everything on screen
>>>>>
This is legitimate.

it doesnt use your video card to do this in hardware if you do find some software hacks to do this, so X is extremely slow.
>>>>>>
Actually, certain X driver (Matrox, NVIDIA) *do* accelerate XRender in hardware. Quartz, right now, does everything in software, and can't even theoretically do stuff in hardware (blame Display PDF) without a lot of overhead in translating the format.

KDE better than OSX? hell no, check back in 2-3 years and maybe you'll be right.
>>>>>>
It's already better from a features point of view, and in terms of locks, it's a wash. OS X has window shadows and smooth icon-zooming, which KDE doesn't have, but the fact that it's actively hostile to theming give KDE an advantage. The only thing missing is a vector API , which will arrive in months rather than years (check the XRender mailing lists). The future, however, is outside both KDE and OS X. The future is stuff like EVAS and Longhorn, and OS X has the disadvantage that it's display model is so closely tied to DisplayPDF it will need some significant reworking to compete with those.

Re:Kde3 better than OSX? What are you smoking?

[HanzoSan]

OSX is not bitmaps, its vectors.

OSX does realtime scaling this means you can scale a movie down in realtime while its playing and see it playing while its happening, it also allows you to scale icons in realtime, this is mainly due to the PDF based API and the design but it manages to do it.


Actually, certain X driver (Matrox, NVIDIA) *do* accelerate XRender in hardware. Quartz, right now, does everything in software, and can't even theoretically do stuff in hardware (blame Display PDF) without a lot of overhead in translating the format.
Xrender is not powerful enough is my point.

OSX jaguar uses Quartz extreme which does everything in hardware, you are thinking of the Quartz which was released years ago not the current.

The future is stuff like EVAS and Longhorn
Rasterman has totally given up on Linux on the desktop, read the interview
Linux on the desktop dead by Rasterman

Longhorn looks just like XP, Microsoft is working on it, but if you honestly believe Microsoft is innovative enough to actually be the future of the desktop, you must have been blind for the past 5-6 years.

OSX has its flaws but Display PDF works very well, Its working better than Longhorn, and better than Linux, perhaps in 5 years when Microsoft catches up and in 2-3 years when Linux catches up Apple will be just about ready to release OS11.

By the way I've checked out the mailing lists, a Vector API takes longer than months to develop, its going to take them at least a year to fully develop it considering its only 2 guys writing it. Thats why I said 2-3 years Linux will catch up, because it will take about a year for the Vector API to be complete, then another year for KDE to actually use it, then another year before all the themes are actually made to take advantage of it, so 2-3 years is a good estimate.

Re:Kde3 better than OSX? What are you smoking?

[be-fan]

OSX is not bitmaps, its vectors.
>>>>>>
Quartz deals with both bitmaps and vectors. Unfortunately, nearly all the chrome (scrollbars and whatnot) are just bitmaps. That was my point. Aqua has the potential to be totally vector based, but it isn't.

OSX does realtime scaling this means you can scale a movie down in realtime while its playing and see it playing while its happening,
>>>>>>>>
Everything since Win98 has done this! This is so trivial, it's expected behavior.

it also allows you to scale icons in realtime, this is mainly due to the PDF based API and the design but it manages to do it.
>>>>>>>
Both KDE and GNOME have the infrastructure necessary to do this (see the GNOME SVG icons). In fact, unlike OS X, GNOME can even draw it's widgets as SVG graphics.

Xrender is not powerful enough is my point.
>>>>>>
The only thing XRender is missing is the vector API, which is being worked on as we speak.

OSX jaguar uses Quartz extreme which does everything in hardware
>>>>>>>>
Common misconception. "Quartz Extreme" is actually an enhancement for Quartz Compositor not Quartz 2D. It allows the compositing of windows and stuff like the genie effect to be hardware accelerated, nothing else. The Quartz 2D software renderer draws windows to textured quads, and these quads are draw via OpenGL onto the screen. Thus, the only thing being accelerated are window-level special effects (drop shadows, etc) not actual drawing.

Linux on the desktop dead by Rasterman [linuxandmain.com]
>>>>>
Rasterman isn't exactly the only person who can do this. EVAS will live on, or something like it. It's just too good not to. Take a look at E17's evas_test program. It's unbelievable. Even at this early stage, it can draw complex alpha-blended vector graphics at 100 fps, *fully* OpenGL accelerated.

Longhorn looks just like XP, Microsoft is working on it, but if you honestly believe Microsoft is innovative enough to actually be the future of the desktop, you must have been blind for the past 5-6 years.
>>>>>>>>
Microsoft did DirectX, and DirectX, in its modern iterations is one hell of a great API. It seems to be that the DirectX guys have a hand in Longhorn (desktop accelerated via Direct3D, for example) and I don't doubt that Longhorn's hardware accelerated desktop will kick ass. Who cares what it looks like (OS X people, sigh...)? The technology underneath is amazing. It's not innovative (it is kind of a no brainer at this point that the desktop should be accelerated via 3D hardware) but the idea is solid.

OSX has its flaws but Display PDF works very well, Its working better than Longhorn, and better than Linux,
>>>>>>>>>
Display PDF works fine, but it really was not the right rendering model to use. It would've been smart of Apple not to tie itself to something that really couldn't be accelerated in hardware easily. As for working better than Longhorn, Longhorn isn't due out for several years. Or are you judging by those leaked screenshots of an alpha build?

By the way I've checked out the mailing lists, a Vector API takes longer than months to develop, its going to take them at least a year to fully develop it considering its only 2 guys writing it. Thats why I said 2-3 years Linux will catch up, because it will take about a year for the Vector API to be complete, then another year for KDE to actually use it, then another year before all the themes are actually made to take advantage of it, so 2-3 years is a good estimate.
>>>>>>>>
Welcome to OSS time scales! A lot of the core infrastructure is already in place (thank's to XRender), and they have a good base (Postscript) to cue the design off of. If the speed of development of XRender, Xft, and FontConfig are any indication, those X guys will speed through implementing the vector API. If XRender and XRandR are any indication, KDE will support the vector API before it even becomes available in a stable X release!

Re:Kde3 better than OSX? What are you smoking?

[HanzoSan]

Welcome to OSS time scales! A lot of the core infrastructure is already in place (thank's to XRender), and they have a good base (Postscript) to cue the design off of. If the speed of development of XRender, Xft, and FontConfig are any indication, those X guys will speed through implementing the vector API. If XRender and XRandR are any indication, KDE will support the vector API before it even becomes available in a stable X release!

XRandR and XRender are not fully supported by KDE, but they are partially supported which, we are just not getting the support for anti aliased fonts and we still dont have alpha channel, (well we do but its not REAL alpha channel). I think you are right they could do it within a year but its not going to make Xfree86 4.3 and Xfree86 5.0 wont be here for about a year. There arent any plans that I know of to release an Xfree86 4.4, its 4.3 and then 5.0 so this means the release coming this Jan is the last Xfree86 release until Xfree86 5.0, this is why I say at least a year, not because I dont think they could get some of the parts done within this year, as a whole package it wont be done until 2004 or late 2003.



Display PDF works fine, but it really was not the right rendering model to use. It would've been smart of Apple not to tie itself to something that really couldn't be accelerated in hardware easily. As for working better than Longhorn, Longhorn isn't due out for several years. Or are you judging by those leaked screenshots of an alpha build?

I can agree with that, that Display PDF is not perfect, but it does have its advantages, yes the Vector API coming for X will be better than Apples, but its too far away right now, at least over a year.


Microsoft did DirectX, and DirectX, in its modern iterations is one hell of a great API. It seems to be that the DirectX guys have a hand in Longhorn (desktop accelerated via Direct3D, for example) and I don't doubt that Longhorn's hardware accelerated desktop will kick ass. Who cares what it looks like (OS X people, sigh...)? The technology underneath is amazing. It's not innovative (it is kind of a no brainer at this point that the desktop should be accelerated via 3D hardware) but the idea is solid.

Nice technology but lets not forget whos making this technology, Microsoft. They arent exactly open source, so you wont be able to use the best technology unless they let you, and I dont think the default interface Microsoft comes up with will be anything special unless they completely rip off OSX and Linux like they usually do, Luna vs Aqua? And nice job of them adding the little Linux style bar to Longhorn as if they came up with the idea.



Rasterman isn't exactly the only person who can do this. EVAS will live on, or something like it. It's just too good not to. Take a look at E17's evas_test program. It's unbelievable. Even at this early stage, it can draw complex alpha-blended vector graphics at 100 fps, *fully* OpenGL accelerated.

Yes Evas is great, and Evas 2 is even better, the problem with Evas is, its moving at a speed thats too fast for X to handle. Rasterman himself told me we wont have an Evas desktop for at least 2 years, this was around a year ago, so we have one more year left, I expect when Xfree86 5.0 comes out, then you can use Evas to render the desktop, until then however Evas is just a toy.

Common misconception. "Quartz Extreme" is actually an enhancement for Quartz Compositor not Quartz 2D. It allows the compositing of windows and stuff like the genie effect to be hardware accelerated, nothing else. The Quartz 2D software renderer draws windows to textured quads, and these quads are draw via OpenGL onto the screen. Thus, the only thing being accelerated are window-level special effects (drop shadows, etc) not actual drawing.


True Quartz Extreme doesnt fully render the interface, I never said it does, I was talking about the special effects. Currently no interface is completely hardware accelerated, If Linux ever gets to THAT point it will blow OSX out of the water. This will take a very long time though, theres alot of video cards to support, a standard must be made and alot of code written unless they use OpenGL or something already written like Evas does.Its going to take Xfree86 a long while to do this, I think we will start to see it when Xfree86 5.0 is released, maybe support from a few Matrox cards, maybe Nvidia and ATI, The best reason this would be good is because the interface could use ram directly from the VideoCard making everything much much faster, you could do better than the Genie effect, you could do the T2 effect and have the Widgets and Windows morph in realtime from liquid to solid and it wouldnt slow anything down.
When we get to that point, thats when Linux would begin to dominate the desktop for the casual user, If Linux could do that yet Microsoft and OSX couldnt, that would give casual users a reason to switch to Linux.

People dont switch to something thats just as good as Windows, stability and security casual users dont give a damn about, but cool eye candy is what attracts them.

IT works with Movies, it works with Video Games, it works with Music Videos, It works with Ads, when you have something that looks pretty it gets more attention from the masses.

Re:Kde3 better than OSX? What are you smoking?

[10Ghz]

The future is stuff like EVAS and Longhorn
Rasterman has totally given up on Linux on the desktop, read the interview

Rasterman believes Linux on the desktop is dead simply because Rasterman doesn't work on the desktop anymore. He does belive that linux will rule the embedded market, and it just happens that he works on the embedded stuff these days. It seems to me that the things where Linux will rule according to Rasterman is the stuff Rasterman works on. The things he doesn't work on are doomed to fail.

Not My Problem Syndrome

[T-Ranger]

Part of the "problem" with the UNIX world is the rampant Not My Problem Syndrome. No one says "the buck stops here"... One of the reasons why, ie, BeOS, was a good OS was because everyone was under one roof. At the end of the day they goal was to produce a good OS. While modularity is a good thing it brings with it the Not My Problem Syndrome. Window manager teams blame X. X blames window managers. Everyone blames libc. Kernel hackers blame driver writers. Driver writers blame hardware manufactures.

Usability isnt the issue, Quality is the issue.

[HanzoSan]

Linux looks like shit because it has no Alpha channel effects, Note I didnt say transparency, thats not what I mean, what I mean is, the ability for windows to have diffrent levels of alpha channelling.

This is VERY useful, look at OSX and see how its used, even WindowsXP uses it when you move your icons, the icons become transparent so you can see where you are moving them.

The cursor also needs to become transparent so that it can have proper shadows and look professional, the fonts would also look better, along with the windows.

This isnt about usability, geeks care about usability, WindowsXP isnt the most usable, neither is OSX, you have to balance usability and presentation.

Linux is already easier to use meaning better usability than Windows in most areas, the only real problems left are the lack of polish, Linux still looks amateur, KDE3 can add all these nice effects but if they all are fake, the whole thing looks like a hacker OS that it still is.

Things need to look professional, and this is the purpose of eye candy.

Re:Usability isnt the issue, Quality is the issue.

[be-fan]

First, the ability of windows to have different alpha values *is* transparency (more appropriately translucency). It *is* useless.

This is VERY useful, look at OSX and see how its used, even Windows XP uses it when you move your icons, the icons become transparent so you can see where you are moving them.
>>>>>>>>>>
Um, how exactly is this useful? First, I doubt you can make out two tiny icon-sized images alpha-blended together. Second, if you're drop target is the size of an icon, there is some serious design error. Besides, Linux has it too. I don't have desktop icons in KDE (I hate icons) but if I did, they'd be translucent when moved.

The cursor also needs to become transparent so that it can have proper shadows and look professional,
>>>>>>>>>
Um, shadows on cursors looks cheesy, not professional. Are you telling me that before Windows 2000 and it's drop shadow effect, there was no professional looking GUI? Beyond that, you're just wrong on so many levels. All cursors (since like Windows 2.0) have transparency (they're two bitmaps, a color one and a mask). That's why it looks like an arrow rather than a big square. Besides, the XCursor extension (already in XFree CVS) does drop shadows and animation and all that.

the fonts would also look better, along with the windows.
>>>>>>>>
Um, translucency at the screen level (which X doesn't support) has nothing to do with translucency at the window level (which X does support, via XRender). Translucency at the screen level is needed for window drop-shadows, while translucency at the window level works just fine for anti-aliased text. On top of that, my AA fonts look better in X than in Windows, and a hell of a lot better than OS X.

This isnt about usability, geeks care about usability, WindowsXP isnt the most usable, neither is OSX, you have to balance usability and presentation.
>>>>>>>
Usability is king. If something can look nice and still be usable, great. If looks interferes with usability, you've fucked up the design.

KDE3 can add all these nice effects but if they all are fake, the whole thing looks like a hacker OS that it still is.
>>>>>>>>>
How is it fake? I've got transparent menus and cool eye candy in KDE, and I sure as a hell can't tell the difference between it and OS X, aside from the god-damned window drop-shadows. There are two rendering models at work here, and despite what Apple would have you believe, Aqua's isn't better than X's.

X has a model that maps very well to current hardware, and is very fast. Do benchmarks if you don't believe me on the 'fast' part. I've done them, and X whips some ass. As a trade-off for this, it has to implement certain eye-candy tricks as hacks. This is just fine, because eye candy isn't drawn that often anyway. If the user doesn't notice, it's working just fine.

Aqua uses a model that does not map well at all to current hardware. It's coupling to DisplayPDF precludes a lot of hardware acceleration possibilities, and it uses inordinate amounts of RAM. However, it enables certain things like window shadows and the genie effect to be done "naturally."

The major problem with Aqua is it trades "real work" performance for "stupid eye-candy" performance. That's a no-no.

(Note, I'm just comparing the window rendering methods. Aqua's *real* killer feature is the Quartz vector API, which Apple unfortunately does half-assedly by rendering everything to giant bitmaps...)

Things need to look professional, and this is the purpose of eye candy.
>>>>>>>>>>.
Um, even Apple realized that it had to cut down on eye candy to look more professional. Hence, Aqua Graphite.

Re:Usability isnt the issue, Quality is the issue.

[shellbeach]

I don't agree with the original poster either, but I think his point about window drop-shadows is valid. At least, it's the single most useful aspect of alpha-blended transparency ... transparent menus and windows are crud, but those drop-shadows on MacOS X look as though they'd help a lot to distinguish windows on a cluttered desktop.

And I've got to admit, based on 10 minutes playing with OS X, Apple handles the eye-candy pretty damn fast. It certainly impressed the hell out of me, and I've never given MacOS the time of day before.

Re:Usability isnt the issue, Quality is the issue.

[HanzoSan]

m, how exactly is this useful? First, I doubt you can make out two tiny icon-sized images alpha-blended together. Second, if you're drop target is the size of an icon,


Let me give you an example, In OSX or in WinXP, take a file, drag it, see the nice shadow below it? You also should see that while its moving, the object you are draging is translucent, meaning you can see whats under it, this doesnt sound useful? when you are moving pictures this is damn useful, its also useful from a usability point of view, when you drag something you want to null what you are draging, so you make it translucent, the shadows gives it a better 3d look so it seems like you are acting draging it over something and not just teleporting it.

Linux has horrible drag and drop animation, when you drag something into the browser you see some weird paper looking animation or something, its not the same at all. Have you moved folders in OSX? You may think the scaling and shadows is just eye candy, but think of it this way, sit a newbie down, and let him look at both OSes, which one would he choose? The one with the nice eye candy, or the other OS which does the same thing but with no eye candy at all?



How is it fake? I've got transparent menus and cool eye candy in KDE, and I sure as a hell can't tell the difference between it and OS X, aside from the god-damned window drop-shadows. There are two rendering models at work here, and despite what Apple would have you believe, Aqua's isn't better than X's.

Drag a movie while its moving in KDE, does the movie go translucent and still play while you are dragging it? Noooo, you have to see the whole pause while you drag it or worse, the movie takes up space on your screen while you drag it around past your browser, chat window or whatever you are moving the movie from blocking.

X has a model that maps very well to current hardware, and is very fast. Do benchmarks if you don't believe me on the 'fast' part. I've done them, and X whips some ass. As a trade-off for this, it has to implement certain eye-candy tricks as hacks. This is just fine, because eye candy isn't drawn that often anyway. If the user doesn't notice, it's working just fine.

Sadly, OSX is much faster than X even if X is fast. X may be faster than Windows95 and OS9 but its definately not faster than OSX or XP, considering both fully use the hardware.



Aqua uses a model that does not map well at all to current hardware. It's coupling to DisplayPDF precludes a lot of hardware acceleration possibilities, and it uses inordinate amounts of RAM. However, it enables certain things like window shadows and the genie effect to be done "naturally."

And to the average user, thats all that matters, they dont give a damn about how fast you can compile a kernel, they dont care how much ram is used considering all they do with their 512 megs of ram is browse the web, these people want something that looks nice, not something that looks like shit but runs nice. Linux will always be a geek OS as long as people keep trying to tell the casual user stuff like "so what if its not as pretty, it gets the job done, its stable, its open source" Like the casual user gives a damn.

The casual user wants an OS which looks pretty, an OS which is easy to use, and they want to be able to run their software, thats it. They dont care if the OS is using alot or alittle ram, they dont care about CPU resources, they dont care about "real work" performance. People who care about "real work" performance are programmers, and business men, not a teenager who wants to surf the web with pretty fonts etc.

"Um, even Apple realized that it had to cut down on eye candy to look more professional. Hence, Aqua Graphite."

Aqua Graphite still has all of the special effects and eye candy, its alittle bit less colorful, so what? OSX can be serious for serious users and it can be pretty for casual users, casual users want something thats pretty, if they wanted serious they'd have been using unix in the first place and we wouldnt be trying to convert them to linux users.



"Usability is king. If something can look nice and still be usable, great. If looks interferes with usability, you've fucked up the design.
"

Translucency does not interfere with usability when done right, OSX has done it right, learn from the experts and do it right. A translucent terminal might not be your style, but I'd love to have one. Done right, it wouldnt bee translucent by default, but the ability would still be there.


"
Um, shadows on cursors looks cheesy, not professional. Are you telling me that before Windows 2000 and it's drop shadow effect, there was no professional looking GUI? Beyond that, you're just wrong on so many levels. All cursors (since like Windows 2.0) have transparency (they're two bitmaps, a color one and a mask). That's why it looks like an arrow rather than a big square. Besides, the XCursor extension (already in XFree CVS) does drop shadows and animation and all that."


Before dropshadows, Windows was ugly as shit, unfortunately that was all there was at the time so people had to deal with it, it was the best there was. Find me one person on the planet who doesnt know a thing about computers who prefers the look of plain Windows95 over the look of OSX or Windows 2000 and you can prove your point.

Like I said, when done right, translucency, genie effect, animated icons and so on, they improve the user experience, when done wrong they annoy the user, it all depends on how its done.

Sure you can over do it on the special effects, but you can also under do it, currently linux doesnt even do fonts properly, the genie effect or I should call it realtime scaling would also be useful for linux users, especially users with multiple desktops, the alpha channel would be useful for people who keep the terminal open at all times, and want to be able to see the terminal update while they surf the web.

Oh and when people want to watch movies and surf the web, multitasking, they shouldnt have to choose which one they get to see, they should be able to see both if they choose to, this means the movie should be able to go alittle bit translucent so they can read whatever website they are reading, you can have a button to turn this future on and off.

I suggest you try using OSX for a while, you'll see how they use this eye candy in useful ways, if you can show a newbie OSX and they tell you its harder to use than Windows95 or Linux, then you can come here and talk about usability vs eyecandy

Re:Usability isnt the issue, Quality is the issue.

[Arandir]

People who care about "real work" performance are programmers, and business men, not a teenager who wants to surf the web with pretty fonts etc.

Then may I suggest that the teenagers stick with OSX while we programmers and businessmen get on with the real work.

Re:Usability isnt the issue, Quality is the issue.

[Anonymous Coward]

I've worked with OS X Jaguar ever since it's come out, and believe me, as soon as the system takes a little load the GUI gets extremely slow.

Translation:

[Anonymous Coward]

It's not X. Therefore it sucks.

Berlin v Kitchener

[maddog2o_2o]

Why call it Berlin? Well, why call it Kitchener? or New York for that matter. Naming is usually to do with the founders though. In this case they were predominately German. So they chose a name that reminded them of home. I'm from Nova Scotia (latin for New Scotland) and we've got a New Glascow and an Inverness amongst many old names from across the water.

Hrrrm, but what could've be happening 'around 1910' that would cause them to change a name that reflected their proud heritage?

W hy W ould I not want people to think I was a proud German? *shrug* It's one of those things we'll probably never know. :)

Kevin

Re:CORBA? Perhaps SOAP!

[axxackall]

CORBA is not reaally overhead - it works fine in GNOME. But CORBA is obsolete. The main problem is that CORBA was not designed for asyncronous messaging from the first place. And that is bad in a real world with real firewall admins.

I think SOAP is much better than CORBA to bring a network transparency to GUI. SOAP is more flexible and more language independent (People who tried CJava comm over CORBA will understand).

Unfortunately, SOAP has problems too:

• SOAP will give more overhead if you'll try to use it to deliver individual pixels and mouse events. Although, it's a solvable and configurable tradeoff between latency and overall performance.
• Today SOAP is controlled mostly by Microsoft. I doubt that company will contribute anything to any good open source project. Although, Microsoft itself has some chance if they'll try something like GUI.NET

I wonder if Mono will be capable to sustitute X in future.

CORBA

[avdi]

If it helps explain it at all, CORBA isn't known for being used by PHds. It's generally used by engineers in software companie3s trying to get real work done. Which is not to say that there's anything wrong with being a PHD; just that the academically oriented and the pragmatically oriented tend to use very different measures when determining a technology's worth.

Re:CORBA

[Anonymous Coward]

If it helps explain it at all, CORBA isn't known for being used by PHds. It's generally used by engineers in software companie3s trying to get real work done. Which is not to say that there's anything wrong with being a PHD; just that the academically oriented and the pragmatically oriented tend to use very different measures when determining a technology's worth.

Or maybe, it is just that PhDs know about several dozen of remote-invocation protocols and systems, and are appealed at the utter heavyness and uglyness of the design-by-commitee CORBA stuff, while most engineers in software companies don't know any better than whatever is hyped today (C++, ObjectiveC, Java, C#, Python/Perl/Ruby... etc ... industry has a hard time catching on Smalltalk 1980).

Re:My only question is...

[fsmunoz]

Interestingly enough in European Portuguese "Fresco" means someone naughty, that does naughty or unusual things.

The origianl meaning of the word is. of course, the same: 'ar fresco' == 'cool air', 'peixe fresco' == 'fresh fish', etc.

The term 'fresco' is, by these reasons, the term used to describe paintures made directly into a wall or ceiling while the cover is still fresh, and it is an internation term IIRC.

egards,

fsmunoz

One in a million

[[cx]]

There have been lots of so called replacements for X in the past years.

But none have had the effort nor the ability to last as long as they do. In this long you'd think X would be a little farther along, but it's not really X's fault. Ever use X / Fluxbox?

Ever use X/Gnome/KDE? MUCH SLOWER. And you ask why? We don't need a replacement for X, we need an open source standardized window manager.

Yes it's good and merry to have multiple libraries, multiple differently rendered fonts, multiple choices, etc. But I personally would rather not have to worry about installing 40-50 libraries when I use my nix box.

[xcxxcx]

Re:One in a million

[shellbeach]

Yes it's good and merry to have multiple libraries, multiple differently rendered fonts, multiple choices, etc. But I personally would rather not have to worry about installing 40-50 libraries when I use my nix box.

OK, so ... don't install 40-50 libraries!! Use Fluxbox if that's what you like and live happily ever after! Remember, you don't have to install KDE or Gnome (unless you want to use one of the g* or k* apps - but I can't really see why you'd want to).

Linux is about choice, and that by definition means not having a "standardised" window manager. If you want a single, fast window manager, a single set of standard libraries and no options or choice, then use Windows. That's what it's there for. Linux exists for the people who want something just a little bit different.

How soon we forget.

[Inoshiro]

"Also back in the late 1990's many linux users still used pentium 1's and 486's with only 32 or 64 megs of ram! The client/server nature of X was not only inadaquate but it was considered bloated and obsolete."

Yea, just as bloated as on my R3k 25Mhz with 16mb of RAM, right?

Wrong. X11 servers with proper frame buffers ran on stuff wimpier than my Palm Vx with no problems!
XFree86 has always been the problem. That is why so much work went in the 4.x tree towards making the drivers not suck, and why we're starting to see those efforts pay off.

Now it just needs a little more in the basic spec to support more modern windowing features, as well as making everything easier to automate. End users don't want to know about copying dot files with X11 auth permissions, they just want a magic "Roam" button which lets them take their desktop elsewhere in the house.

time to change the /. motto.

[ignorant_newbie]

No longer is it news for nerds; now it's

"News for wannabes who are too lazy to find out what something is on their own and insist that the slashdot editors explain everything to them in small words".

I suggest a forking of the community: /. visitors using IE or AOL will be redirected to the wannabe version, and the rest of us won't have to wait 2 hours for all their posts be be modded down before reading the discussion.

Re:time to change the /. motto.

[sethadam1]

Ah...the classic Slashdot elitist finally has a face!

Slashdot is a website that aims to increase readership. Note that Linux as a whole still has a virtually invisible market share. It seems that zealots like you would prefer to keep it that way because for some reason you seem to be more entitled to it than those who don't have the unlimited time you apparently do to sit around and surf the net to research every available option and program.

I have frequented Slashdot for some time, and comments like yours are about as intolerable as the "BSD is dying," "How about a Beowulf cluster of...," and "Cowboy Neal does so and so."

Get off your high horse. This is the community as it is today. Why be bitter?

Re:time to change the /. motto.

[Anonymous Coward]

>It seems that zealots like you would prefer to keep it that way
I know I would, and I don't consider myself a zealot.

installshield v.s. emerge

[ignorant_newbie]

and the emerge system never asks me to "trust all content from microsoft corporation". If i want to see what something does, i just look at the ebuild file.

Re:CORBA? Perhaps SOAP!

[Anonymous Coward]

you sir, are terribly stupid or a terrible troll. perhaps both.

too little too late

[Anonymous Coward]

and it's GPLd now :(

Re:My only question is...

[mrg]

Hey in Argentinian Spanish it is the same as in European protuguese. Well, it seems interenting to learn about the diferences in our langauges even though we are close to the brazilians. By.

Fresco

[blair1q]

A classical fresco is a painting on damp ("fresh") plaster, with the paint penetrating the wall. As such, it tends not to flake off as a painting on dried plaster would, and can last for thousands of years.

This Fresco is cheap middleware on a product of limited utility, and could last for thousands of days, maybe. Maybe not.

Re:CORBA? Perhaps SOAP!

[Tumbleweed]

If you're concerned about MS 'mostly' controlling SOAP, as you should be, then you'd likely be interested in XML-RPC .

Go to Walmart

[HanzoSan]

Buy the $200 Linux PC.

The only reaosn Linux isnt selling off the shelves at Walmart is the fact that Windows is more perfesionally looking even if Linux is bette.

GOOD.. ITS ABOUT TIME.....

[Anonymous Coward]

X was good for its time, but its defintly bloated and could die for all i care. Having a good vector based windowing system/manager like Fresco i think is a HUGE benefit. I hope this project does well..

Disappointing

[Anonymous Coward]

I hope Fresco never does well. First of all it's LGPL'd. Second it will probably never have the refinement of X, because big companies like Sony, Fujitsu, and others will probably not want to work on an LGPL'd window system. If you're a communist this is great, but if you live in the capitalist world you will be disappointed. Just remember RMS likes to call people that make money from software "parasite"s (see him bashing John Ousterhout).

With images turned off

[yerricde]

I have the images and stuff turned off. I'm sure other people do too. X doesn't show up on that preference.

It's in both the "alt" and "title" attributes of the img element.

Re:An intro that actually introduces would be help

[sinserve]

No seriously, what the HELL is the "West Bank"? I know western union, but
they are not a bank, thats fo sho.

Prince - Symbol - Prince - ???

[Anonymous Coward]

Err.. you mean the graphical server previously known as O(+> (or simply X??).
AFAIK he's back to Prince again ... waidaminit, what day is today?

Fresco Software Project exists.

[Martin S.]

This is a bad name, a 'Fresco' open source software project already exists. It is an Mozilla derrivative browser for STB's and has been around since the open sourcing of Netscape.

http://www.antlimited.com/products_fresco.html

Re:Fresco Software Project exists.

[Anonymous Coward]

They changed the name of the 'Berlin' project back to the name of the project that inspired it's creation and architecture. 'Fresco' started at least four years ago.

what about audio?

[EdIsSoKewl]

okay, maybe this is a little off-topic, but what about audio support? these network-transparent windowing systems are great and all, but it only stands to reason that if a program i'm running produces audio output that i'd want that output directed to the same host that is managing my display. with all the current implementations that i'm aware of, redirecting audio to follow the display is a huge pain in the ass. i wish fresco or x had an integrated audio mixer and transport scheme to transparently sent the noises to the same place as the pictures.

Re:what about audio?

[t_hunger]

We are looking into gstreamer, MAS (multimediaapplicationserver.org iirc) and other projects. No concreate plans are made (yet) Anyone interessted in sound on fresco? ;-)

Except it is still confusing.

[Anonymous Coward]

To avoid confusion, the project name was changed to "Fresco". The window server is still called "Berlin".

But this is still very confusing because Fresco is a C++ based widget/GUI interface for X11 based on Corba.

DRI is not used for X?

[Anonymous Coward]

According to this page "The DRI is an integral part of XFree86 4.x..."

Re:CORBA? Perhaps SOAP!

[Hard_Code]

Wow...all I can think is wrong wrong wrong.

You DON'T want SOAP. Have you ever SEEN a SOAP message? It's insane. What you want is a small, binary packet based protocol. The overhead of just PARSING SOAP would totally swamp latency. Yuck yuck yuck. I have developed seriously with CORBA, and while I am not enamored of it (the spec is just way too big, flexible, vague, byzantine and incomprehensible), SOAP is an even "wronger" answer. If anything, you need to go in the other direction - small, binary, application-specific protocol. CORBA is the next best thing, while gaining you portability and lots of existing support. (actually I wish somebody would just implement a native, simpler, RMI to replace CORBA - CORBA is overkill for a lot of things). Think KParts (or whatever custom protocol KDE came up with).

You have alpha/transparency swapped

[spitzak]

You have swapped the meanings from what most people are using.

ALPHA: This means that rendering is able to mix the color that is already on the screen with the new color. But usually it does not keep the original input, so once the colors are mixed they cannot be un-mixed. Another way to state this is that you are painting with "transparent paint". Once the paint is on the wall you cannot get it off, you can only paint over it with more opaque paint.

Alpha is tremendously, vitally important for modern graphics. Many drawings can only be efficienlty stated by using overlayed alpha drawings.

Alpha can also be simulated without any hardware or X server support whatsoever. The end result is *IDENTICAL*. Speed and bloat in the application programs is the problem.

TRANSPARENCY: This is usually taken to mean the storage of alpha in the server. Usually this means that the compositing is done at the last moment, perhaps by hardware, though it could also mean using math tricks to "decompose" the images back apart. The purpose of transparency is so that you can change the overlaying image without having to redo the underlying one (most people think of just moving the overlaying image or changing the layering order, but in fact the overlaying one can be transformed or redrawn arbitrarily).

Oddly enough the first "hardware graphics acceleration" was a type of transparency. "Sprites" were hardware supported long before any graphics, since they allowed objects to move quickly. Even the earliest X servers supported a mouse cursor with some transparency. (of course both of these were 1-bit alpha but the fact that hardware was dedicated to this long before drawing lines or bitblt is interesting).

Currently transparency is most useful for putting anti-aliased edges on objects that move around rapidly, ie overlapping windows. This allows them to be shapes other than rectangles. With partial transparency they can have nice curved shapes or faded edges (ie drop shadows).

It is not practical to do this outside the window server. Not only is it slow, it would require an enormous amount of cooperation between all the programs, and is probably more difficult to design than something inside the server.

There is a lot of similarity between Alpha and Transparency, but often they are implemented with totally different pipelines. It would be nice if the designers made the interface identical (ie you start with a transparent window, and the paint you use also accumulates for that transparency) but from what I know the designers have been too stupid to do this so far.

Re: CORBA for network transparency

[doodaddy]

I'm glad to see some "orthogonality" in library design for a change!

Is CORBA a wonderful network transparency layer? I don't really know, but I'd still rather use it and keep the issue "under" the graphics system. Same for a security layer, etc. Too many people have to roll their own out of naivety only to find out that the issues are complex.

Good job! I remember liking Berlin a couple of years ago for the cleanliness and sincerity of the on-line information. Keep up the great work!

heh

[avdi]

You mention Ruby (which is hardly "hyped" these days) and then you say "industry has a hard time catching on to Smalltalk". You haven't used Ruby have you?

Anyway, your comment essentially agrees with me. Academics are concerned with elegance and perfection. Engineers are concerned with whether something actually works, interoperates well, and solves the problem at hand.

Out of curiousity, exactly what did Smalltalk add to the field of remote invocation? And how was it better than what has come after? Smalltalk has influenced a lot of the best tools & techniques in software engineering, but RMI is one area where I hadn't noticed it having any impact.

Last Post!

[alpg]

Bypasses are devices that allow some people to dash from point A to
point B very fast while other people dash from point B to point A very
fast. People living at point C, being a point directly in between, are
often given to wonder what's so great about point A that so many people
from point B are so keen to get there and what's so great about point B
that so many people from point A are so keen to get _____there. They often
wish that people would just once and for all work out where the hell
they wanted to be.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

- this post brought to you by the Automated Last Post Generator...