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."
its about time someone does some decent work on the actuyal framework of the xserver, because right now, most limitations are not due to the window manager, rather the server.
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
How much is "not too much"? Any modification may be enough to break an existing X application. So what will it break?
Thankfully most of my favourite X applications are open source and actively maintained, so if this takes off I suppose they will be fixed if necessary (or at least fixable). An exception to this would be the old Loki games, which are neither open source nor maintained. I suppose this demonstrates one reason why closed source is bad...
cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement! x finally becomes less about boring rectangles, and becomes truly fun to hack ;)
Lets hope this gets support from enough different groups to make it a standard.
And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)
Assuming xlib isn't statically linked, I don't think there'll be too much of a problem. I'd even venture a guess that simpler applications wouldn't be affected at all.
tasks(723) drafts(105) languages(484) examples(29106)
We returned a new 19" monitor the other day because it was native 1600x1200. The text was unreadable at that resolution and lower resolutions simply looked like crap. We replaced it with a 1280x1024 bit but that is still on the small side.
The last time that this was brought up on slashdot, most of the arrogant jerks tried to point out that you can "simply adjust the font size in the control panel". This doesn't work for anyone who has tried it.
Longhorn will take a big step forward in this area. They will be rendering the window system and applying it as a texture so that the DPI of the monitor is irrelevant. X will be light years behind if it doesn't do this first.
Life is the leading cause of death in America.
The main principle here seems simply to be for the X-server to store each window, wether it be visable or not. At the moment if you stack windows on top of each other the X-server forgets what is on the covered up bits, and when the window becomes visable again it is redrawn. This was a good idea back when memory was scarce, because storing X full screen applications could take X*screensize memory. However today with more memory, we can store all those windows without forcing a redraw.
This is long overdue in X, and also as stated makes things like alpha blending, and Mac OS-X style openGL window-dragging acceleration much more trivial, and also for those who like network transparency, won't require resending windows each time they become visable (although adds the new problem that unless you are careful you could end up spending lots of time sending updates to non-visable windows). It is of course nessasary to allow some chucking of hidden windows (because full screen 32-bit images still take up quite a lot of room), but overall its a good plan!
Combination - fun iPhone puzzling
Let's summarize the discussion that this is going to trigger:
Whine 1: X is slow and bloated we need a replacement.
Response 1: The XFree86 implementation may be slow and bloated and not the protocol.
Response 2: Come up with something better and we'll talk.
Whine 2: Who uses the remote display capability of X anyway?
Response 1: On local displays X uses shared memory and is fast enough.
Response 2: If 5% of the users need the feature it should be retained.
It's really important for me to be able to get to my PC from the lab (as I am doing now) and run all my apps (thank god for switched networks and gigabit ethernet - I'm using 1100k/sec at present, it used to only be possible to use 16 colour mode 800x600 VNC because of network congestion, now 24 bit desktops forwarded over SSH is fine). As such the biggest reason I wouldn't consider jumping to Apple is the fact that on Linux X 'just works' in a networked environment. I can browse local and remote filesystems with no pain at all, and it's very responsive.
If X is going to get the ability to do OS X's flash graphical tricks (the useful ones at least - functionality before form please) then this will make my desktop experience much more plesant, whilst still giving me a stable and predictable environment wherever I happen to be working. Even if the flash tricks are only available locally (at least until the college upgrades to terrabit ethernet...) it'll still be a pretty big bonus.
Beep beep.
"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 ?
Aqua is based on Display-PDF and is resolution independent. That was a really smart move by Apple because resolution is only going up. Even if there were small problems with resolution being to low on laptops (don't think so) this will go away in the future. All bitmap-oriented window systems will suffer from this design decision increasingly.
At the beginning was at.
This seems to be a band aid solution and complex as well. With OpenGL being so prevalent why not create an X replacement entirely upon it?
an ill wind that blows no good
I seem to be seeing a new X logo as well from the slashdot page:
slashdot.jpg
It's so simple and plain. It just might work!
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
What would be really nice is if we could have X11 with integrated audio. There are lots of ways of streaming audio, etc., but that is different.
What I want is that when I log into a remote X11 box using xdm the audio is sent to the local X11 server, just as the video now is. All the processing would be done remotely, and just the video/audio rendering for local hardware would be handled locally.
Best wishes,
Bob
Every X replacement for UNIX has pretty much failed. FAILED. failed.
Why? There is a huge investment in XFree86 in things like drivers. It would take *ages* to implement all of that again.
X was made to be very small, clean, and extensible. It still is today.
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.
...was to be able to cut and paste between applications. A unified API for a clipboard system that uses a unified set of keys to cut and paste.
Alpha blending should be miles and miles behind the development of a window system that actually works.
But, this looks to be more typical X development. No brake pedal, but you can shift gears via the steering wheel, the stereo, or a series of buttons on the sunroof; it has 539 airbags, each requiring a different pressure to go off, and there's a seatbelt interface for every previous seatbelt in existance. Plus it has the most efficient 46 horse power engine ever made, even though opening the glove compartment causes it to stall, or at least backfire.
~Wx
sig?