I'd originally posted this elsewhere
but think it's apropos here (lightly adapted).
Note that I'm not an X or graphics developer. I have watched SW
development, and free software development in particular, for
years. Observations are based on what I've noted of successful and
unsuccessful projects over the years. From what I can see, Fresco
doesn't have what it takes. Fluffy Grue could probably speak to some of
the technical issues I raise.
Some point out the Fresco project as an
alternative to X. Taking a look at the Fresco v. X FAQ , I'm pretty
underwhelmed. Well, not completely. They do use a Wiki....
1 Consistent user interface policy
One of the problems with the X Window System's flexibility was the
accumulation of several inconsistent GUI toolkits. New users are often puzzled,
when they see that their Netscape window looks different than their Gimp
window, which in turn looks different than the rest of their KDE desktop.
Fresco takes care of the user interface by itself without calling upon the
use of GUI toolkits to render buttons, menus and scrollbars. This way, all
widgets in the applications on the desktop look alike. Eventually, Fresco will
support theming, which will be truly universal theming.
This is the old "interface consistency" chimera. Several problems:
- Interface consistency comes from one source: imposing an interface on
all apps, regardless. E.g.: no choice. For instances of this, see Mac OS/X
and legacy MS Windows.
- Of course, consistency means that there's no support for alternatives.
Which means that you don't have support for legacy apps built to other
- ...unless, that is, you provide backwards compatibility. In which case
you're back to square one: the interface isn't consistent, so long as
legacy apps (and newly emerging toolkits) are supported.
- Meantime, the problem with the "single approved method" solution is
that opportunity for experimentation and initiative, or dare I suggest
innovation, are reduced. Multiple toolkits means
different methods, presentations, mechanisms, etc., can be explored.
Including the whole ORB vs. API interface issue.
- Even the platforms with "GUI consistency" (why does that phrase make me
queasy?) don't. legacy MS Windows is burdened with, well, legacy MS Windows
GUI toolkits. Not to mention a set of new apps which ignore the system
toolkit to provide their own. In one case encountered recently, itself a
clone of the system GUI...if you're running WinXP, though it looks oddly
out of place on Win2K, or with "Classic" themes applied in XP. Mac's got
its Aqua/Cocoa issues.
Conclusion: Fresco either can't deliver on this promise, or presents a worse
situation if succeeds, failing the compatibility requirement in the process.
2 Alpha transparency
An often wanted feature of XFree86 has been support for true alpha
transparency. The Free Software community has worked around this limitation
in various ways from copying the background image into the X terminal to a
very alpha translucent GTK+ theme. The Enlightenment window
manager has been able to achieve the translucent moving of windows. But
real alpha transparency has yet to be added.
Fresco has alpha transparency today. You can see this on Fresco's
Note that they're transparent windows, not just the background
image - generally, Fresco's architecture allows for anything to be
transparent, from a single widget to the entire desktop.
OK, color me stupid, but how the hell does Alpha transparency rate as the
number two argument in favor of Fresco? I could give a f---. I really could.
As Fresco itself admits, there are hacks in X to support transparency.
Several in development. Googling doesn't indicate whether or not this is
something that can be readily supported without major architectural hacks.
Still, a graphics hack of limited utility is hardly a reason to toss an entire,
working, debugged, entrenched graphics subsystem.
3 Resolution Independence
Most current graphical enviroments are pretty much pixel-based.
Each window is so-many pixels high by so-many pixels wide. This is
why, when you up the resolution of your environment, all of your
windows shrink, giving you more room. Then the user changes the size
of the fonts used for text so that he or she can read everything
In contrast, Fresco uses vector-based drawing and supports
arbitrary linear transformations of the desktop. This means, in
part, that the desktop can be scaled to any size the user wants.
This makes pixel-based units more or less meaningless. Fresco uses
common sense laymen units for sizes: inches, centimeters, or
millimeters. This guarentees that the size of an object on a 15
inch screen is the same as its size on paper, which is the size of
an object on the big viewscreen at NASA (assuming someone ported
Fresco over). Thus users would be compelled to use the highest
resolution/color depth possible for the visual quality rather than
for the space on their desktop or the size of the text.
Seems to me this is the sort of thing which can be handled in a desktop
environment, handling the translations for the user. With reporting of
properties from smart monitors, probably trivial.
One of the big problems with resolution independence in X is that nobody
Couldn't 'a said it better myself.
4 Programming Language Independence
Fresco achieves programming language independence by exposing its
API through CORBA. Any language that has bindings for the
ORB can be used to create Fresco applications.
...meaning the ORB model has to be embedded into each programming
language, as opposed the the X11 API. Yawn.
There are enough implementations of the X API that the programmer isn't
restricted to any particular programming language. Or scripting tool. The
work's been done. Fresco, by contrast, would require additional work to
develop both the API and train developers.
5 Network Transparency
Like the X Window System, Fresco provides network transparency.
Great! We can tear out all the plumbing to have...the exact same
functionality. This isn't an improvement, it's a lateral move.
The difference is that Fresco uses CORBA for network
transparency while X Window System uses the X Protocol which is much
lower level. So where Fresco transmits the creation request for a
button and click events on that button, X transmits the look of the
button each time it gets moved/redisplayed after being obscured by
another window plus all events that happen inside the window the
button is displayed in.
...so not only is it a lateral, it's a backwards-incompatible lateral.
Unless X protocol events are also supported. In which case you might
want to look over the uniform interface discussion above.
5.1 Alternative Explanation:
Like the X Window System, Fresco provides network transparency.
Fresco accomplishes this by using CORBA for network
communications, while the X Window System uses the X Protocol.
While it has been noted that IIOP (the network protocol
underlying network communications in CORBA) has more overhead than
the X Protocol, Fresco still manages significant advantages.
The X Window System specifies a set of graphical operations to be
provided by the server. These operations are not well suited to the
modern environment of true-color displays with hardware
acceleration, and most toolkits and client programs get around the
limitations of X by using XSHM (X Shared Memory Extension) or
similar means to perform their graphical operations local to the
client or toolkit, and provide X with a bitmap to render.
Fresco improves upon this by providing a very sophisticated suite
of operations on the server, all of which act on an in-server vector
representation of the screen. This permits complex operations such
as transparency and arbitrary transformations to be represented with
single IIOP requests.
So while IIOP may have more overhead, the overlying Fresco
communications will be much terser than corresponding communications
under the X Protocol.
Which would be a substantial improvement...on 4mbps ethernet. GigE's
got bandwidth to spare. X runs usably over 56K lines via compression and
low-bandwidth proxies. For broadband (DSL and better) connections,
distance is invisible for most common business needs. Issues of latency,
rather than bandwidth, are more significant for most GUI response, and
be addressed by either bandwidth or network traffic.
Largely: network capabilities are such that this doesn't particularly
matter. There are far less efficient protocols than X which run over
networked connections, usably.
6 Advanced Text Features and Internationalization
Fresco has copious support of Unicode. This means that Fresco is
capable of rendering all languages supported by 16-bit Unicode. In
the X Window System, Unicode support is still in development with
the [WWW] Pango project.
In addition, Fresco supports text operations such as kerning and
ligatures that are required for non-latin-based character sets.
Ligatures and kerning can also make latin-based text look better.
Improving font and characterset handling in the graphics environment
would be a major plus. Unfortunately, the characterset situation is
getting seriously unweildy. Original ASCII was 127 characters, extended
to 256, in several incompatible encodings (thank you, BillG). With
various extended byte (with various deltas on numbers of bytes)
encodings, not only can't you tell what a character is without doing
signifcant decoding of the bytestream itself, but the possible encodings
go into the tens of thousands, if not millions. It's a mess.
And dumping this mess into the middle of the graphics subsystem is
the Wrong Place To Put It.
Put characterset handling in its on separate module. Let that module
talk to the graphics subsystem. We're going to trash this whole thing
several times, and the less collateral damage the better.
Oh: and I'm completely ignorant on most of this, I'm parroting bits
recalled from bookstore conversations with folks involved in Asian
charset projects with HP, and some of Larry Wall's discussion from
various Perl docs and State-of-the-Onion speeches.
7 Device Independence
Fresco's API was designed to allow you to separate presentation
from content. Taskets, which still need to be defined, will leave
the rendering up to the server, so that the same application can be
used on a palm pilot, printed onto a printer, spoken to a blind or
hands-off user or rendered in true 3D. Those with low hardware
resources may choose to use the application on a text terminal. All
this is blue-sky at the moment.
What Fresco does provide today is resolution independance (see
above), allowing it to render the same content with good quality on
a wide range of display / print devices. In comparison, try to run X
[apps] with a 1200 dpi display :).
This is blue-sky today and will be blue-sky in a century.
Device-independence in a GUI system isn't something that can be extended
to bitmapped to full-screen text to interactive line mode to
text-to-speech devices. GUI apps are fundamentally interrupt driven.
Audio environments are principally batch-mode one-dimensional -- and
that dimension is time.
It's possible that a single toolkit could assist in this process.
It's also more likely that providing a backend-frontend design based on
toolkits specifically tuned to the needs of each environment.
Another misguided aim of Fresco.
Responsive UI, Scalability etc.
See sections "Pervasive Multithreading" and "Multithreaded User
Interface" of the [WWW] BeOS Whitepaper for a description of the
Sure. When I get a round TUIT.
9 Structured graphics
The most radical difference of Fresco to X is how the content of
the display is created by the applications. It would go too far to
explain it here, check out ArchitectureQuestions , especially
question "What's the relationship between Fresco and
TheFrescoProject? What is Fresco, anyway?" and the other documents
referenced at the top of that page.
Again, it would be more compelling to describe the benefit succintly
10 And if that doesn't convince you...
Sigh. Good thing programmers don't moonlight as comics...
Fresco has been in development for five years. When Berlin 0.1
was released (3 years ago), much of the code had been rewritten and
the design has been completly revamped. In other words, this time
it's for real . We have more in common with Fresco nowadays than
with Berlin 0.1. The terminal marked the release of Berlin 0.2 and
its first useful application.
So, what we've got:
- Four misguided, useless, or specious benefits.
- One lateral. Without backward compatibility.
- Possible internationalization benefits.
- Another unfulfillable, misguided benefit (device independence).
- Two unarticulated benefits.
- A bad joke.
- Five years' development.
Well, at the very least, I would hope that in another five years we've
got a good joke.
I see few if any real concerns addressed by any of this, much
complexity, and a lot of pie-in-the-sky.
Wager: Fresco's dead. $100 says it won't be signficantly used in ten
Is it useful? Yes. You're suprised? Well: Berlin, Fresco, and similar
projects are a good way to explore various concepts and features. I expect most
of these will be rolled back into X11, or an X11 replacement (I'm not saying X
won't be replaced, but it's going to be a tough sell). As it stands, Fresco's
an iceball in a hot low point, with commensurate chances.
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]