Slashdot Mirror
Next-Gen X Window Rendering For Linux
Bytal writes "Seth Nickel, a GNOME hacker, has an extensive treatment of the next generation Linux graphics technologies being worked on by Red Hat and others. For all those complaining about the current X-Windows/X.org server capabilities, things like 'Indiana Jones buttons that puff out smoothly animated clouds of smoke when you click on them,' 'Workspace switching effects so lavish they make Keynote jealous' and even the mundane 'Hardware accelerated PDF viewers' may be interesting."
i wrote a paper on this topic for my CG1 class, and it covers most of the modern display systems with a few right around the the horizon.
i'm hoping cairo/glitz will give quartz extreme a run for its money. now we just need to get started on implementing something similar to coreimage/corevideo!
- tristan
Granted, Enlightenment is a window manager that lives on top of the existing X protocol, but nearly every single piece of 'eye-candy' this guy mentions is already do-able in E17.
Sounds just like the themeing system in E17 to me... http://enlightenment.org/pages/systems.html
Don't get me wrong, the things Seth describes sound cool, but the way he describes it makes it sound like they're the only ones with these ideas, when in fact Enlightenment 17 is already enabling most of what he mentions in this article. Sure, it's not a "production" release yet, but DR17 is certainly usable today, and has most of the features he mentions.
Heck, some things Seth talks about (Live window thumbnails) have been available in Enlightenment for quite some time (I know DR16 has them, and maybe earlier versions as well)
Keep in mind the taskbars and menu's were highly influenced from NextSTEP before MS added them into Windows. Same with using a graphical language like postscript and now pdf.
Also gnome is very macintosh like and one of the early macintosh developers wrote nautilus if I recall.
No one is stealing anything. Even the menu bars on the top of the screen came from Xerox before Apple used them.
What I like about kde and gnome to some extent is that they are highly customizable compared to either mac/windows. The problem is the later versions of kde look a little cluttered as a result but you can make your desktop look like anything.
Also you can have kde put a menu on the top of the screen just like gnome and macos. I think you can add a task bar to gnome as well.
I think perhaps some new innovative idea's are needed instead of just borrowing existing ones. Perhaps a way to handle many apps running at once without the desktop looking cluttered is next.
But I believe(could be wrong) that Windowmaker,kde,gnome all use ghostscript which is a postscript clone. The original macos and nextstep used it. Windows has an equilivant but I do not remember the name since its been a long time since I admined Windows boxes.
http://saveie6.com/
The entire OpenGL-composited interface is described using PDF
I sobbed when I read this.
I wrote a really long post correcting this widely and wrongly held opinion some weeks back. I don't feel like finding it, or being that verbose again. So short versions.
No PDF, no OpenGL.
Quartz 2D is a display-list engine, but it is not a PDF interpreter. Rather, Apple wrote some very, very simple shims that quickly translate PDF files into Quartz 2D display lists and back. Nothing in Quartz 2D is represented in PDF format unless it's sitting in a file on the disk.
The windows are drawn on the screen by a piece of software called Quartz Compositor. A couple of years ago, Apple rewrote Quartz Compositor to take advantage of hardware acceleration. They did use OpenGL for this, but only in a very limited way. Each window is represented as a texture on a surface and fed to the graphics pipeline for compositing.
Quartz is amazing. Nothing else in the world comes anywhere close to it, despite what some very confused people seem to think. But you're really selling it short when you describe it as "PDF and OpenGL." Because it isn't.
OS X is wonderful, to be sure. But it is proprietary and only runs on Mac hardware. Xorg is open source and runs on many operating systems and architectures. Big difference. You will continue to see Linux improve in the coming years and there will be more and more Linux desktop deployments. That is the advantage of open source. The battle is far from won. You didn't hear it here first, but you did hear it here.
Celebrate the finer things in life
According to Bruce Horn: "Smalltalk had a three-button mouse and pop-up menus, in contrast to the Mac's menu bar and one-button mouse."
You're raising some interesting points here. Your Windows background does show, but you may be quite representative of what new Gnome users will stumble on their first time around.
:)
:
I'll try to address these points, while avoiding being too technical (which is a pain sometimes
1) Remembering windows size/positions. This drives me nuts.
Okay, okay. You're probably right on this one. However, please consider that a linux desktop is not used like a Windows one, specifically
- people generally use several workspaces and lay out their windows on multiple "screens", so to say,
- you're not supposed to reboot an X terminal as often as a Windows workstation - you just lock it and leave it as is. This comes from older times, but still shows,
- typically, people just arrange their windows *once* and leave them that way. For a very, very long time. When time comes to reboot, they save their session, preserving their windows' position (okay, this does not work all the time) then log back in again later.
Indeed, the X Window System was not supposed to be used like an MS Windows desktop, and the differences still bite us from time to time (why does evolution remember the active pane but not its window position across sessions ? WHY ? Answer : because it's the window manager's business, not his, and e.g. Metacity doesn't support this quite right yet).
2) Hot keys. For the love of god can someone fix hotkeys in gnome! I was used to the alt key toggling the menu of whatever is the active app.
The Alt key is a modifier. It is not a "real" key. It is meant to be used in combination with another "real" key, just like Shift, Control, Super, Hyper, Fn, Apple, etc. It is not cross-platform. It is not standard. It is usually mapped to the Meta key under Linux, which was once used to set the high bit on characters you typed on older terminals. You don't expect something to happen when you press the Control key alone, right ? The same applies to the Alt key.
Use F10. One press of F10 activates the main menu, both on Linux and Windows. Another press dismisses the menu. I don't know about Macs (do they have an F10 key ?) but a real (though nonstandard) key like F10 is much easier to code for than a modifier like Alt.
Hope this helps,
Cheers
ko
Karma cannot be described by words alone.
What can I say? That site is just flat-out wrong. It's an ancient description of an equally ancient Quartz demo, and it gets the internals flat-out wrong.
It says, "Quartz does not use Postscript as its internal graphics representation language. Instead, it uses Adobe's Portable Document Format (PDF) standard which is a superset of Adobe Postscript."
That's just completely incorrect. Quartz 2D graphics are not represented internally as PDF. They just aren't. When a Quartz 2D graphics context is stored in memory, it's stored as a display list, very similar (conceptually) to the way OpenGL scenes are stored in memory. To convert the context to a pixel buffer for display on screen, Quartz Compositor (or Quartz Extreme, depending on hardware) renders and composites the graphics context, which results in a bitmap.
A Quartz 2D display list is very similar to PDF in the way regions are defined and paint applied to them; this makes it easy for PDF files to be converted into Quartz 2D display lists and vice versa. But it's equally true that the Open Inventor file format is similar to an OpenGL display list in the way that vertices and surfaces are defined. You would be wrong to say that OpenGL programs store scenes internally in Open Inventor format; you'd be equally wrong to say that Mac programs store their graphics internally in PDF format. It just ain't so.
Can an Open Inventor model be trivially read from disk and turned into an OpenGL display list? Sure. Can a PDF file be read and trivially turned into a Quartz 2D display list? Yes.
That's it. Okay?
LINUX != x86!
2^5
What do you have to offer other than your word?
Well, an understanding of the topic we're discussing, for starters. I mean, I know what all the words mean, which is clearly something that you can't truthfully say. All you've done is pull quotes from marketing brochures! There's no evidence at all that you have even a passing familiarity with the basic concepts under discussion here.
you're going around claiming Quartz doesn't use PDF for imaging
Correct.
when every developer documentation from Apple directly states that Quartz uses the PDF imaging model
Also correct.
Gasp!
How can this be! How can Quartz 2D both be PDF and not PDF!? He's a witch!
Friend, in order to wrap your head around this topic, you're going to have to understand what the expression "imaging model" means. An imaging model is not a file format, and it's not an instruction set, and it's not an interpreter. It's not actually any type of computer software at all. Rather, it's a way of looking at things.
Back in the old days, we had QuickDraw. QuickDraw used a pixel-based imaging model. You drew to the screen by specifying coordinates in terms of pixels: integer coordinates, bottom-left origin, one pixel was exactly one seventy-second of an inch. Regions were translated literally by shifting bitmaps around in memory. That was the QuickDraw imaging model.
That worked great for drawing to the screen, but it didn't work at all for drawing to a laser printer. For drawing to a laser printer you needed a totally different imaging model. Which means you had to do one of three things in your program: Either you had to maintain an internal representation of whatever you were drawing in whatever form was appropriate for printing and then convert that to QuickDraw for on-screen display, or you had to maintain a QuickDraw representation and convert it at print time, or you had to do both.
But the advantage of QuickDraw was massive: You could draw right into video memory. Toggle a bit in memory and a pixel changed color on screen. Very efficient.
Quartz 2D is different. It uses an entirely different imaging model. Rather than representing on-screen graphics as bitmaps in memory, Quartz 2D creates a layer of mathematical abstraction. With Quartz 2D, you still have a bottom-left origin, but you're not longer on an integer plane. Coordinates are given as floating-point numbers. You don't deal in pixels, but rather in mathematically pure regions of the drawing plane.
You draw in Quartz 2D by defining regions. A region is a locus of floating-point coordinate pairs. For example, (2.1, 3.37), (6.29, 5.3), (7.889, 1.961) defines a triangle. You draw by telling Quartz 2D to fill that region with a certain color, defined by any of the supported color spaces. For instance, you might use RGBA, meaning you'd specify red, green and blue color components and a floating-point opacity value.
Sending these commands to Quartz 2D from within your program creates an in-memory data structure called a display list. This display list doesn't look like anything at all; it's just a sequence of bytes that are encoded to represent the scene you drew. The display list doesn't become anything until you send it to Quartz Compositor (or Quartz Extreme) to be rendered into pixels.
The fundamental assumptions behind Quartz 2D drawing -- the coordinate system, the color spaces, all the low-level details --are referred to collectively as the "imaging model."
PDF has an imaging model that is very similar to Quartz 2D's imaging model. Not identical, but very similar. That's because Apple's engineers were inspired by both PostScript and PDF when they created Quartz 2D.
Because Quartz 2D and PDF use the same imaging model -- the same set of fundamental assumptions --it's very easy to convert a PDF file describing a scene to a Quartz 2D display list that describes that scene. Or you can go vice versa, starting with a Quartz 2