Berlin Packages Released For Debian

A reader writes: "Berlin ^? testing packages for Debian are available from the Debian website and should soon be moved to unstable, according to their the Berlin consortium website." The Berlin website (which looks great, IMHO) has an excellent architecture FAQ - the Berlin vs. X is very well done.Update: 09/01 12:41 PM GMT by H : A number of people have e-mailed me about some....wonkiness...if you view the Berlin vs X page using Internet Explorer. I'd advise using something else.

Comments

Interesting decisions they made

[throx]

The biggest shock to me was the Berlin team decided to use CORBA. Despite several instances in the FAQ of people gasping in astonishment and wanting to know what possessed them to use this heavyweight logic in a display layer, they gloss over any performance issues and seem to shrug off any suggestions of overhead (by either saying the function calls themselves are "almost" native without mentioning the setup times, or comparing to other CORBA based systems). I'd be interested to see some comparisons in display speed between this and XF86 4.0 or Windows just to get an idea of their true overhead.

If I recall correctly the KDE team were originally intending to use CORBA for all their communications but quickly dropped back to their own KOM (based on Microsoft's COM) for their local communication to improve speed and memory usage of the system. Surely Berlin has come up against at least some of the problems the KDE team did and I wonder what their defense for sticking out with CORBA is?

Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".

Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!! Wouldn't a far better way to go be to leave at least the current window square with the screen (and possibly tap into the 2D performance of your hardware) and at least have some methodical way to place other windows in 3D (if you must), while having severe restrictions on their ability to update...

While very cute and all, I just don't see this becoming a successor to X, Windows or Mac user interfaces.

Re:Interesting decisions they made

[Anonymous Coward]

CORBA is NOT heavywieght. Or at least, it doens't have to be. It's about the same overhead of a virtual function call in C++, if done right.

KDE were using CORBA, but found that it was too big and slow. But that was because they were using a big and slow ORB!

D'OH!

There's no reason that the 2D hardware can't be used to optimise the imaging subset of opengl, often neglected by driver writers, who focus on optimising opengl's 3d performance. OpenGL is a 2D/3D API, not just 2D.

And anyway, truth to tell, only Matrox makes 2D hardware that's any good these days. NVidia 2D performance sucks suprisingly badly.

Re:Interesting decisions they made

[Yokaze]

KOM is based on CORBA as you may see on this slide, but probably thats why KDE is so slow :).

Most current gfx-cards are more 3d-cards with a little 2D-engine as extra and none of them is slow in 2D.
They can render several 10^6-triangles per second, a window has a astounding 2 triangles. So that won't be a problem.

Furthermore it's a open and evolving standard which even supports rendering videos. (aviplay can use opengl to accelerate videodisplay)
It's a well documented and powerful interface to the gfx-hardware with vendor-support and drivers..

Transparency in 2D is nearly unsupported by hardware (at least I don't know of such things).

The 3D desktop is surely not very useful, but you get it for free, and you don't have to use it.

Re:Interesting decisions they made

[Anonymous Coward]

To the use of CORBA:
We have hardly any communication between client and server: The client creates graphic objects inside the serverprocess. Those are used to redraw and can handle almost every event that happens (only those that change state in the client get send over the wire). You can manipulate the server not to test for the clients existance. Afterwards the GUI of a client stays around after killing the client itself. You can still move the window, rotate it, set the alpha channel, ...

Running inside the same address space the CORBA-overhead basically is reduced to a virtual function call.I think we can handle that:-)

Yes, the KDE example is so often flung at us: Yes, the way KDE used CORBA they are way better of with the KOM they invented. But they need way less functionality then we do.

To graphics via openGL:
you can render anything to openGL, you can although render the graphics to libArt (which dumps a raster to the screen) and is the default nowadays. A PostscriptDrawingKit is in the works too: That way you can print anything that can get displayed on the screen. The printout will of course use whichever resolution and colors your printer has to offer;-)

Oh, Berlin _is_ slow right now. But not for the two reasons you give: We have not yet optimized anything and we have _NO_ hardware acceleration at all.

About screen-aligned windows: In the berlin architecture it would be hard work to have only those:-) A window is just another graphic, you expect a line in a graphics program to be reotateable/zoomable/... so we have to support those operations. Nobody forces you to do it. We do it right now mostly to show off.

Regards,
Tobias Hunger

Re:Interesting decisions they made

[sigwinch]

Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".

The 3D stuff is used because it lets you do neat 2D stuff really fast, and not to make animated 3D windows fly around in space. To support games, the 3D hardware can scale and otherwise transform bitmaps to random locations and orientations on the screen. This is used, e.g., to apply a brick texture to the side of a building in a game. You can draw the application window into a 'texture' and let the video card draw it anywhere on the screen at any size. (With rotation and perspective, if you're *really* feeling silly.)

You can also align the texture buffer on page boundaries, and map the window's "frame buffer" directly into the app's address space. This lets programs have near-direct access to the frame buffer without any danger of blowing away the system.

Re:Interesting decisions they made

[smunt]

1. Maybe, we might come up with a solution. And you can always run your program in a nested Xserver.

2. Berlin does not include any drivers for graphic-card. Instead, it relies on other programs to do that. Currently everybody uses GGI because it has a working implementation working in a X-window. It also works on SDL, GLUT (OpenGL) and framebuffers. Support for other interfaces should be very easy to add.

Re:Interesting decisions they made

[benb]

In case Tobias wasn't clear enough: OpenGL is just an implmentation detail of the server nowadays. In the default implementation actually, there's no OpenGL at all anymore. (I think.) Use DirectX or PDF, if you want. The client (application) won't notice.

Sounds a lot like Apple's Quartz

[Anonymous Coward]

Don't you think? (Quartz is the graphic engine in Mac OS X)

I mean, resolution independance and the fact that it is not pixel based. It feels like it's using vectorial representation of the graphics to be displayed.

Unicode support, that is a big plus and one of the few real advantages of Mac OS X. Integrating this is a good idea. Even if unicode has it's flaws, it's still better.

And of course alpha blending... this is the first thing you really notice in Mac OS X's Quartz and it's one of the major features of Berlin.

I must say, these are good features, and a number of other nice ones. It's good news that graphic engines similar to Mac OS X's are now (will be) available in open source!

Re:I found my reason to try it:

[Anonymous Coward]

We have not tried to build it on BSD recently.
Last year there was trouble with the threading
implementation of BSD (not sure which BSD was actually tried). I heared there were a lot of improvements in that area... it might be worth to try again. Please report any finding:-)

Tobias Hunger

Re:I found my reason to try it:

[Anonymous Coward]

Of course, they don't mention that Keith Packard has now written the X Render Extension for XFree, and it is basically a 2D subset of OpenGL, which does alpha compositing etc - it's the engine behind the antialiased font support in KDE, for example. There's no real reason it couldn't be used more extensively by widget set authors for transparency effects and such.

Of course it's really a stop-gap measure. OpenGL (which does 2D just fine - set z=0) in the Kernel is the way forward :-))

Re:Resolution Independence

[j7953]

Maybe I want to free up screen real estate by switching to a higher resolution.

No. You want to free up screen real estate by switching to a smaller appearance setting. You want to make things appear in more detail by switching to a higher resolution. That's two different settings instead of just one, so this actually gives you more flexibility. At least if the Berlin developers got that right, I haven't looked at how it actually works yet.

Running a lower resolution to "zoom into your desktop" is like slowing down your processor to watch a movie in slow motion. The idea is just wrong. Time and performance are two different (but related) things, and so are size and resolution.

Re:Still has a long way to go

[Anonymous Coward]

Yes, we have a lot more to do. Yes, we are excited about 3D. We did not spend much time on that yet though.

We get the rotation of windows for free. We'd have to spend a lot of time to turn it OFF!

Berlin is rather stable (i.e. it doesen't crash too often), but that's not hard considering how little it does right now;-) We definitly need to speed it up: No HW-support at all (not even blitting most of the time) and no profiling at all yet.

We have a working network layer though. Clients can run remotely right now!

Regards,
Tobias

Re:directfb

[Anonymous Coward]

DirectFB is not at all like Berlin, except that they both have some relation to displaying graphics. Berlin is a windowing interface -- it uses whatever lower-level drivers are available. DirectFB is a system to give programs fast graphics access. Currently Berlin runs best using GGI to do the actual drawing, but work is afoot to make Berlin render just as well over SDL, GLUT, and, yes, DirectFB.

-- Nathaniel Smith, njs (at sign here) berlin-consortium.org