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: http://download.fresco.org/releases.html#1 (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: http://www.fresco.org/namechange.html
Enjoy!
— Nathaniel
Fresco M1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why would you show text rendering like that to the public? Butt ugly!
When I first heard of this 2(?) years ago it seemed really cool. It looked like the future, but development didn’t seem to be doing much. And we heard nothing about it for a long time. Meanwhile, we get Cosmoe, which is somewhat similar. It looks like they have very different architectures, but they are both new display servers(proper term?) on top of Linux. Both are a long way off from completion.
I certainly wish them both luck, but I wonder it this is really gonna help. I understand if this is “just a hobby” for the developers too, but I really want a good graphical interface for linux!
It would be nice if this release inspired some good support for the Fresco project.
>> Why would you show text rendering like that to the public? Butt ugly!
The fonts are smooth -> http://www.fresco.org/data/screenshots/background.png and the date was 2002-04-28, the news said improvement the look and background..
Anyway, I think Qtopia is kind of looks and sounds better.
Lets see Mozilla running on Fresco. That would probably give Fresco/Berlin instant credibility!
-fooks
This is the shot I was talking about:
http://www.fresco.org/data/screenshots/print.png
Looks like a failed highschool project to me…
Oh. They still live. I remember a few years back Berlin and GGI was the panacea to the old “X11 sucks” adage. And now they can display graphics. Great. Why is it that every linux desktop project seems to think that they can postpone actual HCI design until the very last stage?
Sigh. Those were the days. If I only spent more time with the LIP (the Linux Interface Project. We had a great logo)…
CORBA. *shudder*
I really want a good graphical interface for linux!
sadly, i dont think fresco/berlin is going to be that interface. from what i have seen it is a step backwards from X11 (it has a fixed widget set) and a lot of the earlier advantages (rotating text, alpha transparency) have been put into XRENDER.
in any case the lack of legacy toolkit support (gtk/qt/motif) would kill off fresco before it acheived anything.
what we need is a toolkit which makes programming applications as easy as simple shell scripts. Qt goes a long way towards this and gnustep is looking promising…
It’s really stupid to make comments about something like font quality with reference to a project that is not even in alpha. Right now, they’re trying to get the overall architecture working, fixes in font quality can come later. Besides, it appears that they’re using FreeType, in which case the rendering will look just like every other engine that uses FreeType.
It’s understandable that not everything works right if you’re not even in alpha. The point is that the quality is so bad right now that it hurts their credibility. I could understand if it was development code sitting on their hard drives, but if you show something like that to the world, they’re not going to take you seriously.
What’s stupid is to say “look everybody – see what we can do!” when it looks that bad. So what if it’s development code – my mind is forever going to associate Berlin/Fresco with “ugly”. There’s something to be said for holding back a while until you’re ready – you can only make a first impression once.
If your mind associates Fresco with “ugly” just because of some screenshots we saw of a development release, then frankly you need to get your worldview checked. This is an open source project. It’s not some commercial program that’s “market-driven” with “focus-groups” and glitzy, puke-inducing, over-hyped advertising. They’re sharing their in-progress work because they’re excited about what they’re doing and probably couldn’t care less about “market dilution” or “first impressions.” For the people who actually care about the technology, this is exciting, good fonts or not. What you want is closed development with a big release. Well, that’s not how open source works. The prevailing mantra is “release early, release often” and it’s important to make sure that everybody is in on things. If you’re so superficial that you can’t evaluate a product (when it’s done) on its merits, marketing crap aside, then I’m sure the developers are glad that people like you aren’t using their product!
What’s stupid is to say “look everybody – see what we can do!”
Look everybody, we can rotate transparent views… ugly!
naaaa…
Rayiner, relax. Keep your mind off of my world view and whether you think I’m superficial. (You’re taking this awfully personally, aren’t you?) Maybe the word “ugly” is wrong. What I’m actually concerned about is that they don’t seem able to draw a text string. Specifically, this screenshot:
http://www.fresco.org/data/screenshots/print.png
I don’t give a damn about marketing or focus groups. All I’m trying to say is that I wouldn’t even show work like that to my close friends. Not until my code can at least display something remotely ready for use.
If you put something out there for the public to see, you’re essentially asking for critiques. Appearances do matter – things like this are what make people think of open source as half-assed software.
Fresco may be a great product when it’s done – I just personally would have waited a little longer.
What I’m actually concerned about is that they don’t seem able to draw a text string. Specifically, this screenshot:
http://www.fresco.org/data/screenshots/print.png
That is an older screenshot that shows the progress that the Fresco programmers had made at the time. The following screenshot is a better example of Fresco’s current capabilities:
http://www.fresco.org/data/screenshots/background.png
The Fresco/Berlin programmers have never made it a secret that their project was a work in progress not ready for production. Why call them to task for that?
Exactly. They don’t claim to be the solution to all the world’s problems, why not just let them work, for Christ’s sake. Bitch, bitch, bitch. 😐
Did you even read the article???? Take a look at the screenshots.
-G
The print.png file is showing an example of their postscript renderer. If you dig deeper, you can see that it was pretty much a shot of the postscript printing when they first created it. Since for the most part screen shots do the job right now, postscript output isn’t at the top of their list for things to work on. They know that it needs work.
I agree that it isn’t the best thing to show, but the screenshot page isn’t a “Press Release”, it is more of a collection of things that have been worked on for the last few years (that is why they date them!).
So while it is ugly, it isn’t meant to be pretty yet, they want their GUI interface to be pretty!
Ja
Fresco, Cosmo, PicoGUI. I applaud all their efforts and recognize that they’re all proving grounds for certain technologies. I just really wish that the commercial OpenGL drivers weren’t locked into XFree86. I think that one issue will keep any competitors at bay more than anything else.
Definitely. It’s even hard to get 2D drivers aside from the ones in X. There’s the linux framebuffer, which is supporting more and more hardware but has no acceleration standard. There’s DirectFB, which has the most 2D acceleration support outside of X but still only has full support for the Matrox 2D accelerators.
Anybody interested in a project to make a library that reimplements the X-server-side portion of the XAA (X acceleration architecture) to allow other projects like PicoGUI, Fresco, and Cosmoe access to X video drivers?
Is their something like MS DirectX for Linux ? OpenGL does not seem to do the job right. Windows grahpics allways seem to be much faster than the same thing under Linux. This comment is good for 2D and 3D gfx.
Take UT 2003 demo. On my PC, it runs much faster under XP than Mandrake 9.0 Both have the latest release of Nvidia drivers.
The GUI of XP may be bloated, but respond much better than KDE 3.01 at times.
Just my .02 cent.
I think some clarifications are in order.
1) First off, the comment about print.png – read what’s written next to the screenshot:
“PostScript ability
Guess what you are seeing here: it’s a screenshot taken of ghostscript showing an eps file. Yes, that’s right. We can print now.”
Yes – It’s outputting any graphic object to PostScript for printing. And there’s no rasterization happening – they take the internal vector representation and create an eps out of it. The idea is to give any program WYSIWYG printing for free. But the poster seemed to want to misrepresent it’s intention. The Postscript DrawingKit is a work in progress, and this screenshot was the first time this functionality was working.
In general, the Text functionality does anti-aliasing (using freetype2), but texthandling in a completely device-independent way is definately harder than what other systems do (true subpixel positioning for instance).
2) About drivers: They don’t see it as their job to provide drivers. If and when someone rips out the drivers out of X, they’ll be able to use that. Right now Fresco can use pixels (libart) on GGI (on X or framebuffer for instance) and SDL, openGL on GGI (mesaggi, software rendering, slow), opengl on SDL (on X, hw-accelerated using DRI (or nvidia), fast). DirerctFB support is broken at the moment. But as you can see, their philosophy is: “we use whatever’s out there”.
There’s been voices on the DRI mailing list to separate the 3D drivers from Xfree a bit more. (I think James Simmons – linux console maintainer – for instance brought this up on IRC. Apparently limited 3D cores for PDA’s are almost here). There’s also a proof of concept (fbdri.sf.net), and I think the GGI people are also starting to get experimental hw-acceleration up. (the GGI people can also use the directfb hw-accelerated drivers)
If all else fails, we just strip X to the core (like is done on PDA’s now), put it in full screen openGL, and use it as a big fat HW driver.
This would be not only benificial to Fresco, but for projects like PicoGUI, games, and basically anything for which X isn’t a good fit (yes there are such things).
3) I saw a (negative) post on CORBA. It’s true that corba has overhead, but if they tried to build thesame architecture using other means, they’d end up having to add this overhead anyway. Doing it themselves (NIH) would be duplicating all the work that has gone into Corba. By sticking to CORBA they get language bindings for free, network transparency (remote operation), and a couple of different implementations of ORB’s – so if there’s a fast and compliant ORB coming out, they’ll be able to take advantage of it.
They’re not trying to put individual pixels using corba calls. The idea is to try to use higher-level operations unlike what MicroGUI’s (X) do.
In other words, corba is a damned good fit for something like Fresco. And because it’s being used differently that, let’s say Gnome, it’s not necessarily slow.
There’s alot of FAQ’s on the site about it:
– http://wiki.fresco.org/index.cgi/ArchitectureQuestions
– http://wiki.fresco.org/index.cgi/MicroGUI
– http://www.fresco.org/introduction.html
In general, Fresco has a different scope than X. I personally believe it’s the way forward for GUI’s. Imagine for instance if tomorrow an affordable 14″ display with 3000×2000 pixels came out. It would simply be unusable using current GUI’s (and that includes Aqua – it might be scalable, it’s still heavily device-dependent, works in pixel measurements etc). That’s only one advantage.
It should also be clear that we’re not talking yet about file managers, applications and “desktop environments” like Gnome or KDE. Straight ports from programs wouldn’t always be appropriate either – there’s alot of things that Fresco already provides in the architecture, that you don’t need to duplicate in every program – printing for instance.
It would be interesting to start thinking of a new desktop environment that _can_ take advantage of Fresco’s power. I’m sure the Fresco people welcome ideas, mockups, designs in their wiki, that’s what it’s for. (http://wiki.fresco.org)
Anon: Why would you show text rendering like that to the public? Butt ugly!
Well, as the de-facto PR guy of Fresco (well, almost :-), I have to return for this. Fresco doesn’t have its priorities in font rendering right now. It has its interest is making it useful for software development, than focusing on aesthetics. Font rendering comes in the latter. Font support – Fresco has them, they have remarkable support for Unicode, for example. Fixing the font rendering problem would be almost easy. But once that becomes a important issue, Fresco would be in like M8 or M9.
Please, this is M1. It is literary the first release of their new project. Berlin 0.1 and 0.2 was like the transitional stages. You would see many difference between the two. Besides, I think you are looking at screenshots of previious releases (which all the screenshots, except the Zaurus, is).
Harbinjer: When I first heard of this 2(?) years ago it seemed really cool. It looked like the future, but development didn’t seem to be doing much.
Actually, they have done more in the close than in public. Especially recently. The reason being that their web page was in the midst of a overhall. That change should have happen months ago, but was delayed because
– There were some bugs with the web pages
– Stefan and Nate wanted M1 and the new site to be out at the same time. But some serious bugs prevented a early release of M1.
– Oh, the stupid old issue tracker
It was literary a pain managing the old site, and it seems the only thing being updated was the Wiki :-). Right now with the new site, you would see more update developments.
Harbinjer: Meanwhile, we get Cosmoe, which is somewhat similar.
Cosmoe is very different. It just uses the same traditional resolution-dependant architecture. It may be tonnes better than X11 because it fixes flaws from X11. That is very easy to do.
Fresco on the other hand is not only making something, they are building something completely new. Innovating. In their free time. When you are thinking about a new concept, and trying to resolve the problems that may arise from it, it takes far more time than using conventional wisdom.
Cosmoe is not about making something completely different. It is about bring a few ideas together.
Harbinjer: It looks like they have very different architectures, but they are both new display servers(proper term?) on top of Linux.
Neither are displays servers. Cosmoe relies on the framebuffer as a displa server, while Fresco on GGI (which on Linux depends on KGI which depends on the framebuffer) mainly on its portablity (due to some Solaris and FreeBSD users, it is nessacary).
Harbinjer: I understand if this is “just a hobby” for the developers too, but I really want a good graphical interface for linux!
Then you are better off with XFree86. They are fixing major flaws (like speed, fonts, etc) with their software at amazing speeds.
Fooks: Lets see Mozilla running on Fresco. That would probably give Fresco/Berlin instant credibility!
It certainly won’t be in the current form Mozilla is on other platforms. What Fresco developers would like is a certain amount of CORBA support, a completely native UI, among others.
Anon: This is the shot I was talking about:
http://www.fresco.org/data/screenshots/print.png
Looks like a failed highschool project to me…
LOL, it was taken on the same day PS support was first done. It is much better now. It is a old, hardly functional, version you are seeing.
Michael Dingler: Why is it that every linux desktop project seems to think that they can postpone actual HCI design until the very last stage?
HCI? I’m taking you mean something in relation to a user interface? Fresco is way too immature for that. Besides, Fresco would be using DesktopKits whom decide the UI for the desktop. There won’t be inconsistency like in X11 because there is one standard “toolkit” (well, Fresco was a toolkit…)
Michael Dingler: CORBA. *shudder*
What’s wrong with it? Just because of one particular project didn’t like it because they were just using a small feature set from the standard, and the overhead is immense, doesn’t mean it is all bad.
Or slow.
matt: and a lot of the earlier advantages (rotating text, alpha transparency) have been put into XRENDER.
These features aren’t the whole cause of Fresco or Berlin. It is just to show what the architecture itself can do. XRENDER is just a patch on top of XFree86 to give it these features. It isn’t built into like Fresco.
These features is often showcased to show the vector architecture of Berlin/Fresco, and comparing it with the raster altenative from Windows and X11. Sure, they can do it, but how much work did they put into it to make it work?
matt: in any case the lack of legacy toolkit support (gtk/qt/motif) would kill off fresco before it acheived anything.
Toolkit ports would happen. For sure. Later on. Right now it is too darn immature for such a thing. But if a port of GTK+ and/or Qt, it wouldn’t have its own widget set. if there is anything Fresco hates about X11 because being raster based is the inconsistency.
Besides, did Qt ever had legacy support for Motif? Or GTK+? Running X11 apps on Fresco wouldn’t be impossible. In the same way a X11 implementation (X on X, or XDarwin,if I’m not wrong) can be made rootless on Quartz, so can it on Fresco.
Anon: It’s understandable that not everything works right if you’re not even in alpha. The point is that the quality is so bad right now that it hurts their credibility.
What crediblity. If Fresco has only good fonts to show, I would drop it faster than you can say “Fresco sucks”. Right now, fixing up their architecture is their main priority. When Pango was in alpha, was their fonts anywhere close to good? And now? What about what Rhapsody leaked screenies came out? How was the fonts then? Right. Terrible.
Right now, in order to get good fonts, I think they are better off fixing their architecture instead of patching up the fonts.
Anon: What I’m actually concerned about is that they don’t seem able to draw a text string.
It was considered a bug. And IIRC, it is fix. God darn, can’t you read the caption? Man.
Anon: All I’m trying to say is that I wouldn’t even show work like that to my close friends.
No wonder you have nothing to show for yourself. But a bunch of developers have been working real hard to get Postcript view run. And when they finally managed, shouldn’t they be proud? YES! What about those parents that stick ugly drawings by their babies on the frigde? Because they are proud on their progress. It is no Mona Lisa, for sure, but if you pride is so wrapped on comparing with stuff that is way above Fresco’s league, you need to get a reality check.
When I first saw the screenshot, the first taught was “Aww cool, you guys weren’t lying to me about the PS thing” later on, the fact it was ugly came into mind.
Brian: I just really wish that the commercial OpenGL drivers weren’t locked into XFree86.
Actually, no. Not all. NVidia’s one for example can be used indirectly by Fresco. It’s kernel interface, the part that gives us OpenGL, can be used by SDL, which is used by Fresco.
Micah Dowty: Anybody interested in a project to make a library that reimplements the X-server-side portion of the XAA (X acceleration architecture) to allow other projects like PicoGUI, Fresco, and Cosmoe access to X video drivers?
Maybe for PicoGUI, and by a farther extend, Cosmoe. But Fresco (and Cosmoe too) is too technically different to be this even possible.
Anon: Is their something like MS DirectX for Linux ?
OpenDX, WineX and SDL. Not as featureful as DirectX, but really, big suprise. Coming to the fact that DirectX is a big part of Windows..
Anon: The GUI of XP may be bloated, but respond much better than KDE 3.01 at times.
I notice KDE 3.0.x to be slower than XP on Linux installs that is compiled with GCC 2.9.x, using older versions (e.g. 4.1) of XFree86 and the kernel (e.g. 2.4.8), which is the most trypical Linux install – yeah, you are right. But on the bleeding egde, things are much faster. Give it two or three months, when new distros finally come with KDE 3.1, the newest kernel, blah blah blah, and see how more repsonsive KDE is. You truly would be amaze.
obi: In general, the Text functionality does anti-aliasing (using freetype2), but texthandling in a completely device-independent way is definately harder than what other systems do (true subpixel positioning for instance).
Besides the fact that FreeType 2 is hardly usable with Fresco M1, plus the fact that when it is usable, Fresco hardly takes advantage of it :-). Yeah, I agree with you, give it time. They couldn’t care less about how the fonts render at this point of time now.
obi: In general, Fresco has a different scope than X. I personally believe it’s the way forward for GUI’s. Imagine for instance if tomorrow an affordable 14″ display with 3000×2000 pixels came out. It would simply be unusable using current GUI’s (and that includes Aqua – it might be scalable, it’s still heavily device-dependent, works in pixel measurements etc). That’s only one advantage.
The windowing system itself isn’t dependant on the resolution, but what it is based on is. The difference is that Fresco is able to adapt to different resolutions without breaking a sweat, while using less GPU resources in the process.
Besides, Aqua isn’t slow because it is pixel-based. It is because of a whole lot of unneeded animation. Have this animation be implemented on Windows or X11, it would be way slower.
obi: It would be interesting to start thinking of a new desktop environment that _can_ take advantage of Fresco’s power. I’m sure the Fresco people welcome ideas, mockups, designs in their wiki, that’s what it’s for. (http://wiki.fresco.org)
Right now, it is quite impossile to build desktops, even simple ones, on Fresco. There are too many limitations. These limitations are being broken down. When they do, hopefully I would have already learnt programming, and hopefully be the first to enter this fray…
This is how innovation works, a hundred people try something, and maybe one comes up with something usefull. It’s better to try and fail than just to complain. And these guys are learning a lot from just trying. Even if this project fails they will know what doesn’t work and that’s very important. I bet there are a lot of companies that would love to hire these guys.
> Neither are displays servers. Cosmoe relies on the
> framebuffer as a displa server, while Fresco on GGI (which
> on Linux depends on KGI which depends on the framebuffer)
> mainly on its portablity (due to some Solaris and FreeBSD
> users, it is nessacary).
A correction: GGI does not depend on KGI on Linux. GGI talks straight to the Linux Framebuffer or to a X visual. KGI would be on the same level as the Linux Framebuffer.
At the time when KGI was first proposed, the linux kernel devs felt it should not be included in the kernel. I’m in no position to know for sure, but I wonder if they would have been accepted now, since the kernel devs accepted so much similar stuff (framebuffer, DRM, now the linux console rewrite in 2.6, etc)
My impresssion is that KGI’s non-inclusion was a case of bad timing. In any case, Neither GGI nor Fresco depends on KGI, but if KGI suddenly did become available, Fresco would surely be able to use it immediately.
> obi: In general, the Text functionality does anti-aliasing
> (using freetype2), but texthandling in a completely
> device-independent way is definately harder than what
> other systems do (true subpixel positioning for instance).
>
> Besides the fact that FreeType 2 is hardly usable with
> Fresco M1, plus the fact that when it is usable, Fresco
> hardly takes advantage of it :-). Yeah, I agree with you,
> give it time. They couldn’t care less about how the fonts
> render at this point of time now.
I don’t understand what you mean by this. Freetype is used everytime a pixel-based DrawingKit is used (LibArt DK on GGI or SDL for instance). If you meant that the Text Layout functionality is not ready yet, then I agree with you – lots of discussion are already happening about this. (See http://wiki.fresco.org/TextKitDiscussion )
> obi: In general, Fresco has a different scope than X. I
> personally believe it’s the way forward for GUI’s. Imagine
> for instance if tomorrow an affordable 14″ display with
> 3000×2000 pixels came out. It would simply be unusable
> using current GUI’s (and that includes Aqua – it might be
> scalable, it’s still heavily device-dependent, works in
> pixel measurements etc). That’s only one advantage.
>
> The windowing system itself isn’t dependant on the
> resolution, but what it is based on is. The difference is
> that Fresco is able to adapt to different resolutions
> without breaking a sweat, while using less GPU resources in
> the process.
>
> Besides, Aqua isn’t slow because it is pixel-based. It is
> because of a whole lot of unneeded animation. Have this
> animation be implemented on Windows or X11, it would be way
> slower.
I think you misunderstood me (or I explained myself badly). I’m not talking about the performance. But about how all your applications break in Windows if you try to use high-DPI fonts, just because all application developers (web developers do too!) make alot of assumptions about the range of resolutions.
In short – everything would become unreadable until you switch back to a “normal” resolution.
> Right now, it is quite impossile to build desktops, even
> simple ones, on Fresco. There are too many limitations.
> These limitations are being broken down. When they do,
> hopefully I would have already learnt programming, and
> hopefully be the first to enter this fray…
Yes, I agree. But doing HCI design (taking into account what Fresco brings to the table) before building a desktop environment is definately a good idea. I’m just saying that if you know what your goal is, you’ll be more efficient.
_Because_ Fresco is quite different, this work will be even more important – it’d be silly to just copy (or mix) the UI’s from Windows, KDE, Gnome, Aqua for a system like Fresco’s.
But yes, I do agree that *demanding* this to be done at this stage is quite premature. I was just proposing this to get the discussion into something constructive and interesting, as opposed to trying to defend what Fresco’s doing.
Spot on! Couldn’t agree more.
I never understood where all the agressivity comes from when someone says “I’d like to try something different for a change”
Projects like PicoGUI or Fresco (and others) deserve more support, IMHO.
Micah Dowty: Anybody interested in a project to make a library that reimplements the X-server-side portion of the XAA (X acceleration architecture) to allow other projects like PicoGUI, Fresco, and Cosmoe access to X video drivers?
Maybe for PicoGUI, and by a farther extend, Cosmoe. But Fresco (and Cosmoe too) is too technically different to be this even possible.
Actually, XAA isn’t a very good fit for PicoGUI either- just better than nothing. I’ve also been looking at projects like fbdri, as OpenGL is both faster than XAA on recent cards and would be better for both PicoGUI and Fresco. I already have PicoGUI running on OpenGL nice and fast, so when a project like fbdri does have good card support, it will run picogui fine. From what I’ve seen, looks like Fresco will be the same way.
> Actually, XAA isn’t a very good fit for PicoGUI either-
> just better than nothing. I’ve also been looking at
> projects like fbdri, as OpenGL is both faster than XAA on
> recent cards and would be better for both PicoGUI and
> Fresco. I already have PicoGUI running on OpenGL nice and
> fast, so when a project like fbdri does have good card
> support, it will run picogui fine. From what I’ve seen,
> looks like Fresco will be the same way.
Yep, I agree with this (it was rajan’s comment not mine
)
For the record, I think Picogui is the closest relative to Fresco, so it doesn’t surprise me one bit that you have thesame needs.
I still have some hope for modularized DRI drivers (sadly that won’t include NVidia’s GLX driver) – but I have the distinct impression that for XFree86 devs there’s nuttin’ but X.
Someone needs to go in and rip XFree86’s drivers in modules that can be used without X. After all, “everything can be solved by adding another layer”, right? 🙂
I’m pretty sure it’ll happen eventually. I doubt the Linux FB is satisfactory for everyone.
About the SDL and OpenGL bit. I was under the impression that OpenGL through SDL required X? The drivers certainly, link against the X11 libraries.
As for DirectX, it’s not so much the infrastructure but the drivers. Using the NVIDIA drivers, OpenGL in Linux is actually slightly faster than OpenGL in Windows. Other drivers, however, are not nearly as high quality. UT-2003 is a very specific exception. The lead programmer for UT (Tim Sweeny) is afraid of OpenGL, and as a result, UT-2003 is very Direct3D biased. The OpenGL renderer is of a *far* lower quality.
Yep, you’re right. Currently if you want to run Fresco using HW accelerated openGL, you need to run it in SDL on X. Hopefully that will change eventually.
obi: A correction: GGI does not depend on KGI on Linux. GGI talks straight to the Linux Framebuffer or to a X visual. KGI would be on the same level as the Linux Framebuffer.
Ahh, thanks for clearing that up.
Besides, KGI is being developed currently. Fresco has made no commitments against KGI or for it. If it works, and it is better than GGI to Framebuffer, they would use it.
obi: If you meant that the Text Layout functionality is not ready yet, then I agree with you – lots of discussion are already happening about this. (See http://wiki.fresco.org/TextKitDiscussion )
The wonders of writing stuff at 2 a.m. :-). Yeah, I was talking about text layout, which also includes anti aliasing. Just a history note, a few years, perhaps a couple of years ago, Berlin had better AA than KDE or GNOME. Of course, since then, Fresco had better things to do that fix AA :-).
obi: Yes, I agree. But doing HCI design (taking into account what Fresco brings to the table) before building a desktop environment is definately a good idea. I’m just saying that if you know what your goal is, you’ll be more efficient.
The problem is that Fresco/Berlin guys have been comteplating on not having a standard or even a default desktop, just like X11. The difference between X11 and Fresco is that the UIs are completely consistent though matter what desktop/UI you would because there is only one standard widget set.
HCI diccussions with Fresco developers is like talking microkernel ideas with Linus Torvalds. Sure they want a good UI, but they have no idea on UI design. Having a discussion on the Wiki or the mailing list or its most popular place of discussion, IRC, won’t serve any purposes.
Fresco developers, like Stefan, Nate, Hunger, etc. recognize the fact that they aren’t HCI designers.
However, I hope I would have a say in a future HCI of Fresco. I have a idea that is quite unique yet not as different as Eugenia’s recent ideas. Think of it as a mix between NeXT, OS X, Windows XP and Be OS. Their best UI features of course. (This isn’t your run of the mill “This is nice, that is nice, lets combine them and hope it works!”).
obi: For the record, I think Picogui is the closest relative to Fresco, so it doesn’t surprise me one bit that you have thesame needs.
Its been awhile since I have read up about PicoGUI, but I think the closest relative to Fresco is Quartz followed by Sun’s NeWS.
Rayiner: About the SDL and OpenGL bit. I was under the impression that OpenGL through SDL required X? The drivers certainly, link against the X11 libraries.
Remember, this is via GGI, not the usual X11 drivers (or something that claims to be so). But anyway, all Fresco developers do use X. In fact, last year I found out most of them prefer Window Maker, followed by Englightement… interesting.
I never actually used HW accelaration before, because my first test machine didn’t come with a 3D card with any proper Linux drivers, (Intel 3D), and via Virtual PC, there isn’t much you can get. On my Duron with TNT, which is my Linux machine, I haven’t tried Fresco on it, because of the lack of any net connection to it.