Slashdot Mirror
New X Proposal on Freedesktop.org
Bytal writes "Havoc Pennington (of Red Hat and GNOME fame) seems to have a very interesting entry in his blog on the development of a new extension to the venerable X server going on at freedesktop.org. More specifically it seems to provide for most things that people have clamoring for (alpha blending, flicker-free window compositing and switching, as well as even OpenGL integration) without altering the existing X protocol too much."
Crappie broken slashdot blah
For a free exhibit hall pass use the promo code 'free'.
For 50% off a full access pass use the code 'sctek'
For your enjoyment in case this server is /.'ed:
2003-11-03: New X
The freedesktop.org X hacking is low-profile unstableware at the moment, but one particular proposal interests me the most. Here is how I understand it, I'll probably get it wrong:
The idea is to make the X server model-view. The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times. For each window, the default view copies the window's contents over the contents of the parent window. This results in the same user-visible display you have today - but you could implement alpha blended windows by alpha compositing rather than copying each window into its parent, since we now have the parent window's contents.
To this we add the ability for a "compositing manager" to replace the default view for a given window, using the aXe and XDamage extensions. The window manager might be the compositing manager for toplevel windows, for example.
If a window has a compositing manager, it will not be composited into its parent automatically; the window is invisible until the compositing manager does something. An external compositing manager could emulate the default built-in compositing manager by using XCopyArea() (or alpha-aware equivalent) to copy windows into their parents.
However, a more exciting compositing manager might apply embellishments/transformations to the window contents prior to drawing them, possibly drawing them using an API such as OpenGL. For example, you could add drop shadows. Or you could do effects similar to fast user switching or Expose. Or you could double-buffer the entire screen as a whole making workspace-switching, opaque resize, and other tasks flicker free. The compositing manager is rendering a scene in which the window contents are one element, so the possibilities are endless.
Note that the window contents stay entirely on the server side, the compositing manager uses regular X protocol requests to manipulate them.
Apps other than the single compositing manager can also use the damage extension; possible applications include VNC (desktop sharing), magnifiers, pagers with thumbnailing, and so forth. The compositing manager is a special kind of view in that it disables the default paint of the window to its parent, and is thus responsible for replacing that default paint. But there can be any number of extra views of a window.
There are a lot of little complexities and open questions here, but the idea is pretty interesting. I'm waiting for something I can try out to appear in jhbuild so I can make metacity super-leet.
Sig & Below
Yuck Fou
IIRC, you can change the DPI in XFree86. There should be a setting for it in your display manager's config file.
"The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times."
What are the memory implications of this ?
With many people using resolutions of 1280x1024 or 1600x1200 in 24-bit or 32-bit colour, dual-displays and multiple desktops becoming more common, this could chew up a lot of RAM.
A single, maximised window at 1600x1200/32-bit is going to use 7.5MB, even if it's just a terminal window. I can quite easily have 10 windows open at one time, especially when web browsing (OK, not all maximised, but not all small, either). There goes 75MB of RAM, just for the screen display (let alone the extra memory X uses for pixmaps, etc). If it's constantly being accessed in order to update the display, it won't be easily paged out to disk, either.
Things like tabbed browsers and terminal programs help quite a bit (assuming that the contents of each tab won't be stored in RAM - or will they ?). But not everyone likes using them.
Would someone with more knowledge about the current workings of X care to comment ?
....mention any other open source that can be used as an example of already existing functionality that is like this or can contribute to it, perhaps directly.
Not getting into the programming details but AROS is open source Amiga clone I believe having some of this...
Shrug
Sorry mate, you're wrong. When I change resolution with my XFree86 the fonts stay the same size. The font sizes are calculated based on the dimensions of the monitor. If your fonts were unreadable you had configured something wrong (your distro had configured something wrong, whatever). In this case Windows has been light years behind X for a long time.
However widgets etc. are not generally vector based and thus can look tiny (esp. @ 1600x1200), in this region Longhorn could jump ahead of most free software you use with X. However, all this needs is the toolkit people (GTK, Qt, etc.) to make their toolkits vector based and this will cease to be a problem.
I don't think you deserved your mod points personally.
Uh, this idea is called "backing store" and it's been around since, I believe, X11R4. I'm not sure what this proposal does that's new, other than offer new uses for it.
Given the current bloat of GTK and Gnome when trying to run remotely (even over 100Mbit), backing store is a good thing. When an application lets you turn it on. Which GTK doesn't. Heck, I've even seen a GTK developer claim "X doesn't have any backing store concept." Geez, people, learn your existing technology!
If using gdm, open
append -dpi 100 or whichever you prefer.
HTH
Fortunately the X protocol can be extended without being replaced. OpenGL (GLX actually), Xrender, XVideo and the XSHM (the shared memory extension) are all examples of extensions that have been added without breaking old apps. Parts of X may be crusty, but overall it is pretty well designed.
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
You don't seem to understand the problem the way it was meant. I have a big monitor, I like to run at high resolution, but text is TINY, so I make the fonts bigger, but then everything is out-of-whack in terms of widget sizes and images.
What we're talking about is a VECTOR-based display, so 'increasing the size' won't make it any less readable. In a vector-based system EVERYTHING gets scaled up, you could run the big monitor at 1600x1200 or 512x384 and the elements on the screen would be the same actual size (meaured by a ruler) but the higher-res monitor would just look a hell of a lot better.
Now there ARE some issues that need to get worked out for this, a web browser, for example has to be prepared to have a bitmap GIF 'blown up', and it has to be done well enough to look decent but not take too much CPU power.
NEXT had this, Aqua has the underpinning of it, I think GNUStep is coming along with it, Longhorn is going to have it. I don't see the XFree86 folks picking this up, I think the toolkit folks and KDE/GNOME will have to implement it themselves because the XFree folks are really conservative.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Its a reference to the fact that the bitmapped fonts are only available in those resolutions and might have to be scaled for other ones. Chances are, you aren't actually using any bitmapped fonts any more (most modern apps don't bother, the only one I ever use that does is xterm), so it shouldn't actually affect you. Give it a go and see.
My experience of running X on 1152x900 on a 17" monitor suggests that this is an appropriate resolution that doesn't cause too much issue; 1280x1024 should be more than fine.
I've driven 17" at 1280x1024, and depending on your applications everything works OK. X is a lot more customisable than MS Windows: you can actually change almost any screen font in use in most situations.
I run an IBM Thinkpad with a 15" screen at 1600x1200. In X Windows, I use the Xft2 font renderer, rather than the old core X font system, for almost every text string I see. Because I have also set the DPI for the screen to 133dpi, everything remains clear and readable and the fonts are all the correct size. So if the original parent poster was struggling with a 19" screen at this res, they should learn to configure their systems better.
The biggest problem I have with high DPI displays is viewing web sites, which will need browser technology to change in order to be useful.
Mozilla provides two useful functions at the moment, and there is another one almost there. Minimum text size is useful to stop the worst excesses of tiny fonts. Text zoom is an essential function on bad websites. Image zoom would be nice, especially if it simply runs in step with text zoom. Some tweaks would then be necessary to stop pages being limited to the 800 pixel width that some designers have decided is the perfect form factor.
SVG also offers improvements for high dpi screens. I look forward to the day that Moz/SVG takes over the web browsing domination and web designers really push vector graphics out there.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
How is this different from backing store?
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
I agree. The protocol exists, but it is not yet implemented by XFree86.
I am TheRaven on Soylent News
I suppose this demonstrates one reason why closed source is bad...
Hmmm... closed source is bad because open source hasn't found a way to support it properly? That doesn't sound right. There will always be proprietary software, and OSS needs to get along with it. Breaking proprietary software all the time is not helping spread the adoption of Linux, because most people do need to rely on at least some proprietary software (even if that is just drivers).
Yes, it makes far more sense to have the graphics system act as the server for audio as well, instead of another server. I mean, it's not like there are any networking audio servers out there.
The X11 clipboard is already quite powerful and supports a broad array of selection types, not just ASCII. A lot of apps only support ASCII, but that's not X11's problem. If any toolkit or app is reinventing the wheel by implementing a whole new clipboard, that really is quite brain-damaged.
Ita erat quando hic adveni.
For an excellent example of how to do double-buffering in X, please read the source code (here) for the XSpectrum spectrum analyser (despite its age XSpectrum still runs faster than the newer gspectrum).
Scroogle
Luckily the clipboard problems are simply a lack of standardization between applications. The freedesktop.org people are working on a spec to fix this, and already (afaik) most of KDE and GNOME apps, among others, follow the spec. It's only a matter of time now.
Whenever X11 is discussed, someone brings this up and I give the same reply.
Copy and paste works in X11. It works the same way as MacOS or Windows. You can select text, copy it via a menu item or a keyboard shortcut, select over more text in a different application, and paste in the original text with a menu item or keyboard shortcut. That's it. Pretend there is no middle mouse button and everything will work like you expect.
Now, you're going to run into certain problems with certain ancient applications and toolkits that do not implement this correctly. Most notably, QT 2.x did this wrong and xterm does not allow you to "copy" as you expect (there is no copy menu item or shortcut). I think GNU Emacs also does this wrong. These applications and toolkits are actually fairly rare, but xterm and emacs are pretty popular programs.
Details: X11 keeps track of a clipboard and a selection. The selection is generally inserted whenever you middle-click. Middle-clicking does not paste from the clipboard - you have to use a menu item or keyboard shortcut to paste from the clipboard. Like I said, pretend there is no such thing as middle-click and cut and paste will work as in MacOS and Windows as long as you don't use xterm (instead use gterm or kterm or whatever the KDE/GNOME equivalents are called). Whoever told you that middle-clicking pastes misinformed you; no XFree86 documentation tells you this.
Please don't tell us we need a "unified API" for cut and paste. We have one, it works and all new applications use it. If you want to go and fix xterm, go for it, that's some real nice code for you to play with :) If you want to fix GNU Emacs, go suggest this on the emacs mailing lists and see how far you get :)
The backing store is disabled by default - for local X clients it's slower than just having the client application redraw itself.
X doesn't have any workable backing store concept. By workable, I mean 'capable of being accelerated in a way that doesn't involve shoving the bitmap of the window down a pipe each time'. A workable backing store concept would be one that let the window bitmaps live in video memory - graphics processors can move data around in their own memory far faster than the general-purpose processor can. They also can scale them, make them transparent, or composite several sets of them - with little or no intervention from the CPU. This isn't an arrangement targeted at applications running over the network.
If you want to use the backing store for GTK applications in XFree86, use X +bs. Just don't expose too many windows at once - the X server has to copy the images from main memory out to VRAM, and that's slow.
append -dpi 100 or whichever you prefer
Unfortunately, the font becomes bold once it reaches a certain size, and then it looks like crap. Turning on antialiasing makes it look blurry, and subpixel rendering makes it look off-color and still blurry.
Changing the resolution on an LCD also makes everything look blurry, so that won't work.
A lot of apps only support ASCII, but that's not X11's problem.
Almost any shortcoming in X11 can be fended off by saying "That's not an X11 problem, it's outside the scope of the design". That's not a valid defense. Complaints like that are a sign that although the design may have been implemented acceptably, the design itself is flawed; the scope was too narrow to account for what's needed by a GUI system.
The practical proof of the quality of an arch is the applications that run on it. And practically, non-ASCII clipboard contents in X11 suck. I've just pulled several major desktop apps off Debian Linux and tested their clipboard compatibility.
You can't paste spreadsheet rows between OpenOffice and Gnumeric. You can't copy an image from Gimp and paste it into OpenOffice, Abiword, Kword, or Gnumeric. (Of those 3, only Gnumeric will recognize that the clipboard has anything in it, but it reads it as ASCII junk). An image will copy from Kword to Kword, but not into Gimp, OpenOffice, or Abiword. For every pair of apps I've tried in the past 10 minutes, none could paste an image between each other. Even copying a picture from Kword to Kspread doesn't work! (You'd think that those applications were written by the same team, and would share clipboard protocols)
The only successful copying of images between different applications that I discovered was, rather bizarrely, from Mozilla into OpenOffice. That one surprised me. (Mozilla to Kword does nothing. Mozilla to Abiword crashes)
Having written a few Qt/KDE themes, and perused in depth dozens more, I have to admit that Qt is mostly the same way.
But to be honest, the reason is to prevent bloat. Caching pixmaps uses a lot of memory. For a checkbox, there would be six pixmaps cached (foreground and background palettes for active, inactive and disabled states). This lack of caching doesn't cause a problem for simple controls like checkboxes, because redraws are uncommon.
On some themes, I can definitely see a flicker on slower machines, while on others that appear to be more complex, I see none. For example, Liquid is a pretty complex theme with blended gradients everywhere, but it makes extensive use of caching, so it has a smoother redraw than some simpler themes.
Of course, if this becomes a problem for non-cached themes, it's simple to fix, because of the way Qt is architected.
Don't blame me, I didn't vote for either of them!
Likely the GTK+ developer was me. I certainly didn't say that X has no concept of backing store. I may well have indicated that the current X implementation of backing store quite typically does more harm than good. For instance, under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds in the windows backing store. (Having traced through the X server code to figure out why this was happening some years ago, I can authoritatively say that X does have a concept of backing store.)
Keith's new extension is quite different from traditional X backing store; the obvious difference is the ability to control how the windows are composited to the screen. But there are other differences; the server, for instance, uses only a single backing store buffer for the entire toplevel window, instead of one for each subwindow.