Fresco M1 Released 282
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 '"
Confusion (Score:5, Informative)
Debian packages (Score:4, Informative)
An intro that actually introduces would be helpful (Score:4, Informative)
I know, it's a novel concept, an introduction actually introducing the readers to the subject...
Some basic facts: (Score:5, Informative)
*) 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
Regards,
Tobias
Re:Maybe in 10 years-- no look at their pages (Score:3, Informative)
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... (Score:5, Informative)
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 (Score:5, Informative)
Re:Some basic facts: (Score:1, Informative)
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:Any other Fresco themes besides Motif? (Score:2, Informative)
of course you're free to build a better looking one
Re:Maybe in 10 years-- no look at their pages (Score:1, Informative)
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,
Re:Berlin (Score:3, Informative)
Why the name change? (Score:2, Informative)
Ant Fresco [antlimited.com].
Re:Why the name change? (Score:4, Informative)
We meat the last maintainer from Fresco a couple of times, he told us it's fine with him for us to adopt the name, we got the domain,
Re:You know, Fresco...doesn't ring a bell? (Score:4, Informative)
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:Does Corba have to be Slow? (Score:1, Informative)
Re:You know, Fresco...doesn't ring a bell? (Score:3, Informative)
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!
You've missed the point. (Score:4, Informative)
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:When will Xrender be completed? (Score:1, Informative)
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:Comparison to PicoGUI? (Score:2, Informative)
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