Slashdot Mirror
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 '"
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.
,
faeryman
Debian packages are available from http://non-us.debian.org/~waldi/ . Note that the fresco packages require the omniorb4 packages.
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...
Stupidity is mis-underestimated.
Some comments on other comments that are bound to pop up:
/. experiences I know that these misunderstandingfs/questions are bound to crop 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
Regards,
Tobias
Regards, Tobias
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.
~561
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.
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".
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
fresco has its own network protocol, which consists simply of calling object methods over CORBA.
...). creating objects takes a bit more, thus giving small peaks when starting applications
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,
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."
"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.
"Derp de derp."
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.
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!
http://saveie6.com/
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.
Why bother.
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.
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
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage