Submitted by A Trolltech employee explains how Qt 4.4 will eliminate current problems with redrawing artifacts and poor resizing performance, using windowless child widgets.
Qt Invaded By Aliens – The End of All Flicker
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This looks really exciting, the improvement in the second video is great (even though the resizing still can’t fully keep up with the mouse, but it’s much smoother). Plus, like the Trolltech guy said, the windowless widgets are much lighter on resources. I think it would be very interesting if some GTK+ developer could comment on that, since the GTK+ widgets use their own X windows, too…
> even though the resizing still can’t fully keep up
> with the mouse
screencasts generally suck at showing movement smoothly. you can generally expect the real experience to be better than what a screencast will deliver visually.
Not to devalue Trolltech’s excellent work on Qt, but it seems like this should have been fixed in Xorg rather than worked-around in Qt. A major part of an X server’s job is to manage the stacking, moving, and resizing of client regions. Apparently Xorg is good enough to manage windows but doesn’t scale well to the widgets they contain.
So the question is: what is the underlying cause of this limitation? Is there something different about managing widgets that isn’t merely an extension of managing windows? Is there a shortcoming in the X11 protocol that prevents the efficient decoupling of managing regions from managing their content?
This is functionality that should be common to all GUI toolkits. As the parent noted, it should be implementing in GTK+ and, I’ll add, countless other toolkits. So in the interest of good design and smart abstractions, it makes sense to consider how Xorg can better accommodate widget management.
However, I should also note that Qt targets non-X11 environments. On other platforms, the present approach may make sense. On the other hand, certain platforms may already address these problems in their windowing systems. So there are portability issues here that complicate attempts to exploit commonality.
butters: I fully agree with you. Being a toolkit author myself, I agree. This is something that needs to be fixed in X11 (Xorg) and not in every toolkit out there via work-arounds.
Because of this:
http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the…
Fair enough. I agree with the reasoning in the linked comment thread. Trolltech was right to go ahead and enhance Qt, especially since they are cross-platform. But it’s also important that this generate enough noise to persuade the Xorg folks to make improvements on their end.
Not only non-X11 platforms. While it would be nice if every Unix/X11 platform would be using the latest and greatest x.org X server, a lot are either using older releases (e.g. “enterprise” Linux distributions) or other implementations (e.g. XiGraphics, which doesn’t even have proper XRender)
I really seriously hope they freaking figure out what is wrong with the windowing system in gnome.
I am not sure if its
window manager
gtk
x11
something else
but it sure as hell isn’t just some “synchronization ” problem. When i move windows around the cpu usage spikes like crazy.
I have tried it with open drivers, with closed drivers
I have tried it with ATI video cards and Nvidia video card.. and i always have he same problem.
Something is inefficient somewhere and it is not my imagination and it bothers the hell out of me. I made a movie to describe it
http://www.youtube.com/watch?v=8gh7ABSs1NY
Something is inefficient somewhere and it is not my imagination and it bothers the hell out of me. I made a movie to describe it
Wow, that is seriously messed up. I have a laptop with ATI graphics, using the open source driver, which is absolute crap, and it doesn’t do that. I have seen that effect, and it only happens when the laptop was under extreme load (like compiling something and another app pegging the CPU). At work where I am running the nvidia proprietary drivers, it never happens, even under full load.
This is under KDE though. Try KDE and XFCE and see if it persists. Also try with a different app in the background. Some apps are faster at redrawing than others, so while you might see those artifacts over top of Firefox, they might not be apparent on another app.
Also, this whole problem goes away completely if you enable the composite extension (and you might need a window manager that supports it, dunno if metacity does). With composite, the window in the background is cached, so it doesn’t have to re-render its contents all the time.
Well the video was made with 2 Gigs of ram, athlon x2 4200 and geforce 7900GT 256 MB and the proprietary nvidia driver on gnome feisty
it did it with my previous laptop (an ATI) as well
Edited 2007-08-10 04:41
That video you’re describing is a combination of 3 things.
1) Firefox sucks. It’s slow, buggy, and as the video shows, it really sucks at repainting itself. for example, it turns off solid fills, so that the previous window contents get left behind instead of leaving a solid color, which looks better.
That’s not to say that other apps won’t show artifacts too, but Firefox is by far the worst when it comes to this.
2) You’re not using a compositor. A compositor — even the builtin automatic compositing rules in Xorg — will make this much faster, and remove the repaints. Try it with “xcompmgr -a” if you have xcompmgr installed. That won’t give you eye candy. It won’t even give you transparent windows, but it _WILL_ give you much much faster repaints.
Without a compositor, there is absolutely *NOTHING* that can be done to totally eliminate the “window trail” artifacts, the best you can do is reduce them by making draws faster, and “faking” it by setting solid backgrounds on windows so that you don’t notice the partial draws as much.
windows hasn’t had that kind of lag for years…. and they weren’t using a compositor. SUre using a compositor helps because the graphics card is powerful.. but does it address the underlying issue?
And when i was moving around…. i wasnt even lokoing inside the window. Take a look at the edges of the window frame. I should do another video showing my CPU spiking.
The point is i think that this new advancement for QT.. coudl also be used for gnome and GTK. I am not sure though but i just want clarification. Here is the post that intrigues me:
an application with windowless child widgets is much more light-weight and resource friendly as we don’t allocate native windows for every single widget
s long as X11 is asynchronous (with all its benefits, by all means), resize and move operations will also be asynchronous, and flicker will appear as X11 first clears the exposed area (or leaves a trail of junk behind), then sends an expose notification, allowing the client to redraw. You can probably avoid the flicker with clever use of XFlush, but that will mean performance goes down the drain. With this solution, we don’t only remove the flicker, and remove the need to wait for X11 roundtrips, but we also free up X11 resources as Qt no longer needs the subwidgets on the server side. Which means less memory consumption :->. And on Windows, it means people can create more widgets than they could before…
Windows does have that kind of lag. Again, Firefox shows that lag best, even on Windows, despite the Mozilla foundation’s understandable focus on the Windows market (it is, after all, their biggest market). If you look at the WM_PAINT event in the Win32 API, it’s more or less the exact same thing as the X11 Expose event, with the same issues.
Note that in the original video, there was no problem with the terminal’s redraw (and testing here, even with filled windows, there is no visible redraw except when under heavy load)
As for the final quote that you posted:
– GTK already does similar, except it uses InputOnly windows to figure out where events came from, which means that the code for creating it’s widgets is simpler, and which means that event selection can be much finer-grained. it does *NOT* use subwindows for drawing.
– The QT solution doesn’t really change the amount of roundtrips in most cases, and the X resources that it frees up aren’t very large. I suspect the real win is with Windows, where you can now create more widgets.
windows hasn’t had that kind of lag for years…. and they weren’t using a compositor. SUre using a compositor helps because the graphics card is powerful.. but does it address the underlying issue?
Windows had other problems such as a system lockup when you insert a damaged CD or DVD.
windows hasn’t had that kind of lag for years…. and they weren’t using a compositor
You don’t notice these problems on Windows because the graphics drivers have historically always been better than on Linux. Even the most garbage graphics card has had 2D acceleration for years. So the effect is still there, but redrawing is just about instantaneous so you don’t notice. Any linux with a reasonable graphics driver is just as good.
aah, that’s not true, on a relatively slow system, graphics on windows are always better. This thing they show in the video on that Qt blog is really a problem on linux. And it’s great we can look forward do this finally solved with Qt 4.4!
the huge problem of firefox is that it’s not a real gtk app… or at least it doesn’t use the native gtk widgets, but it draws them for its own using the gtk drawing apis in order to fake the gtk appearance (it does the same thing on windows for copying the xp/vista themes).
and i use it with the gtk-qt theme engine so the disaster is complete
I just tried it on Ubuntu Feisty, my setup:
CPU 5 year old AMD Athlon xp 2400+ (@2Ghz)
RAM 1024 DDR (only 266 speed tho because of CPU/mobo)
GeForce 6 6600 Gt (using nvidia driver)
I don’t know how you captured the video, so I couldn’t capture it (tell me and I will
), but I had virtually no tailing when I moved a small firefox window with your video going in it, over a maximized firefox window over osnews.
Perhaps you got something oddly set or you really do not use nvidia driver (eg: some bug, and x checked back to nv?)
NOTE: I get max CPU usage to about 15% when moving windows around, even over firefox.
Edited 2007-08-10 09:08
well, it’s slow on my amd 2.4 ghz dualcore, with GeForce 6600… But it depends on how critical you are. When I see tearing, it’s bad, that simple. Firefox on windows (2.66 ghz P-III) is also bad, btw. At least it’s noticeable, unlike with other apps. Also, like they do in the Qt blogpost, resizing a part of an app with a lot of widgets is always smooth in XP, unlike linux.
You must have something set wrong then, I NEVER got tearing, and I even do 100% cpu tasks in the background like compilation + this is much weaker machine.
You must have something set wrong then, I NEVER got tearing, and I even do 100% cpu tasks in the background like compilation + this is much weaker machine.
I’m sorry, but everyone gets this on a wide variety of machines. It’s well documented, and has been complained about by a lot of people.
Indeed. Has been a problem like what, forever?
I guess he doesn’t see any problem in the video’s on the blog as well 😉
It may just be me and the way I use my computer but the VAST majority of time I am sitting infront of it, I’m actually working within a window rather than just moving them around the desktop and watching the window trailers. I see it as a feature like the the Mouse Trails in Winblows, albeit one without a preference window…
I really seriously hope they freaking figure out what is wrong with the windowing system in gnome…
Something is inefficient somewhere and it is not my imagination and it bothers the hell out of me. I made a movie to describe it
http://www.youtube.com/watch?v=8gh7ABSs1NY
I used to get exactly the same effect under Gnome on my old system:
128MB RAM, 700MHz Celeron, ATI 3D Rage Pro card, xorg driver.
With my current system:
512MB RAM, 2.8GHz Celeron, Intel i945 graphics
I just cant move the windows fast enough to see anything like that. My current system is hardly a screamer in fact its very basic but it is fast enough to cope easily.
Edited 2007-08-10 12:31
But it seems you’re not using Composite extension, it should not happen there.
I have this same problem in Gnome in Solaris, so I started using dwm.
How much different from BeginWindowDeferPos (http://msdn2.microsoft.com/en-us/library/ms632672.aspx), DeferWindowPos (http://msdn2.microsoft.com/en-us/library/ms632681.aspx) and EndWindowDeferPos (http://msdn2.microsoft.com/en-us/library/ms633440.aspx) in terms of what problem it solves?
I understand how it solves it is quitq different.
Edited 2007-08-10 03:26
All they need to do is get more on to orthogonalizing their toolkit.
When it comes down to it a set of widgets just really is a set of drawing instructions, layering, geometry and event management. The magic is in finding a clean way to make all of them fit together cleanly and orthogonally.
Qt4 actually did a good job api wise for breaking out geometry, drawing instructions and layering. I think their mill stone is the event stuff, and the overengineered MVC stuff, but anyways..
QT + best toolkit ever hnds down. for ease of development and features implimented it has got to be my personaly favorite. wxwidgets is a close second.
Windows doesn’t have those redrawing problems in the first place. I repeated the test and it looks like the second (windowless) video.
Find the real cause in the windowing system instead, and you improve all applications, not just Qt apps. I just cannot get used to the graphics lag in Linux.
It can if the software developer doesn’t use the proper APIs. See my previous post.
I agree 100%. The problem sits with X11 (Xorg).
>>Find the real cause in the windowing system instead, and you improve all applications, not just Qt apps. I just cannot get used to the graphics lag in Linux.
I totally agree. While so so so much work has been done in projects like KDE and GNOME, X11 development (back in the Xfree86 days) seemed to barely be crawling by. I have the feeling that the Xorg folks are starting to make up for lost time, but the fact remains, X is a dinosaur that should be put out to pasture. Sadly, projects like Mesa-solo seem to be the only savior on the horizon, but that could realistically mean waiting another 5 to 10 years (or so it feels) for a well-performing X-less graphical implimentation. Oh, the whoas of free software. If there were some fundraising, I’ll gladly throw some dough their way if this could be sped up.
eLiquid in Pixel had such smooth resizing for more than 5 years now. http://www.pixelimageeditor.com
I can imagine that this technique will put more stress on the X client side and add some lag when xhosting via network. Having independent windows should theorically work better because the XServer does the job of figuring out where to send the event, so latency reduced.
More like, this was the answer from the GTK developers when I asked them about drawing directly (what mentioned in the article) instead of by windows many years ago, and having it optional, because the very slow resizing of gtk was obviously because of this.
This time, I’m glad a developer cares for 99% of the userbase, not the remaining 1%
I have seen this problem in any X11 based toolkit causing X core mechanisms being bypassed by one toolkit after another. (starting with swing).
How come X devs haven’t figured out how to solve it throughout the years forcing toolkits that support it to implement complex hacks? Is is that deeply entrenched in X11 design. If is cannot always perform on both remote and local scenarios some deep re-architecting is needed.
Wouldn’t some new extension be sufficient?
Pardon? there is a replacement, its called XCB. It is part of Xorg already, its people deciding not to support it – that is the problem.
by setting the right flag on the widgets, one can force them to be individual windows at runtime. so in theory if the difference is indeed measurable and desirable, one could create a little tool that walks the object tree and sets the flag (or if one reached down a bit deeper, changes the default flag set) to get the current/old behaviour at runtime for such networked devices.
I already feelt that most flickering was gone in Qt4.1 with all the widgets double-buffered Qt-application were pretty smooth during resizing and moving.
This is can at most be a minor further improvement, Qt4 already kicks GTK in the nuts when it comes to anti-flicker.
“This is can at most be a minor further improvement, Qt4 already kicks GTK in the nuts when it comes to anti-flicker.”
I definitely hope it will be a major improvement (as the video clearly shows) – and badly needed, since on the computers I’ve been trying Qt 4 apps, on both Linux and Windows, the resizing performance is absolutely horrible, just as horrible as the video shows (possibly even worse), even much worse than with GTK+ (which is already bad enough). And not only the resizing performance, but dialogs show up slowly, tab switching is slow etc. Qt 4 really feels very “heavy” (unlike Qt 3, which is an order of magnitude faster).
Edited 2007-08-10 09:21
Resizing windows has never stoped me from doing anything.
Hey, where’s that report?
Qt 4.3.1 (and QTopia) now provides a GPL exception allowing code under different licences to be linked against the GPL.
APL 1.0/1.1, BSDL, MITL and a few others, check [1]
Well, a few from these allow redistributing binaries without source. You have to make available the source to Trolltech on request under these terms though. ( Check 2) in [1] )
That’s a great step by Trolltech – now a lot more projects can use it for own purposes. And if someone wants to hijack the GPL version by utilizing the BSD version and not releasing the code … Trolltech will ask for it and then sell it itself
Nah, I believe they will ask nicely to get a few commercial licences otherwise it will be opened.
[1] http://trolltech.com/products/qt/gplexception
[2] http://www.heise.de/newsticker/meldung/94092 [German]
[3] http://www.golem.de/showhigh2.php?file=/0708/54013.html&wort%5B]=qt [German]
It sounds a bit weird to me that they are focusing their optimization efforts on platforms that didn’t need that much optimizing in the first place.
Qt already performs very well on both Linux and Windows for ‘normal’ applications. However, on Mac OS X, Qt4 has become dog slow (a lot slower than Qt3). Even Java applications feel lighter on OS X. It’s not easy being a good looking/feeling application on OS X compared to all the native apps to begin with, but this makes it a lot harder.
Edited 2007-08-10 09:24
I think QT is going in the right direction (for Desktop users).
The next step is to have the toolkits (QT, GTK, …) talking directly to the compositing engine (linux Beryl, windows DM).
After that, the next step is to have the Compositing engine talking directly to the video card (opengl, directx).
We don’t need anymore an X11-like layer. The toolkits are powerfull enough to manage/render all widgets in one window. The compositing engines can do all the 2D-windows placements. The message bus can be used to do the window/window interaction.
To start off on a mean note, killing X11 would be retarded – that’s what drivers are written for, it abstracts and makes everything nice so everyone else has a clue where to start (as in, it’s not just inertia that it’s still with us). As an extension of this, having the compositing engine speak directly to the hardware would mean different drivers for each – not gonna happen when you figure some people can’t get a decent driver at all. What IS gonna happen, though, is X11 is going to migrate to being fully OpenGL (which is not a hardware spec – it however provides a framework where hardware acceleration can take place. what the videocard can’t do ends up getting done in software (if at all) and moving X11 to OpenGL means that programmers can take advantage of hardware acceleration with much less effort).
I’m sorry if I’m sounding flamey, but it’s posts like this (and the ‘hey guys let’s split the kernel and reap the magical benefits it will bring’ one) that make me wonder if anyone takes the time to understand how any of these underlying systems work and/or WHY they work that way. (I’m also short 12 hours sleep)
I suppose you are talking about Xegl. You can call it “migration” if you like. But “Moving X11 to be fully OpenGL”, as you said, is a major change in X11 “philosophy”. Today, the X11 “core” is not bound to any card-level graphic language. And AFAIK, Xegl will not be a compositing engine.
In a today Beryl-like desktop, most of the X’s job is done by other layers.
– rendering: GPU (texturefrombitmap)
– region clipping: GPU (z-order)
– compositing: Beryl
In Beryl-like desktop, X main jobs are:
– provide a (visible) full-screen OpenGL surface for the display
– provide a (hidden) per-window backbuffer
– draw the widgets
– route user event (mouse/keyboard) to the application
If the widget drawing is done by the toolkit, the paint/repaint will also be externalized.
So, from my point of view, there is 3 ways to go:
1. Add all the features of GPU+Beryl+Toolkit in the futur Xegl
2. Keep X as a simple router of user events.
3. Remove X and do the “event routing” in an other layer
Edited 2007-08-10 12:47
Sorry, but X does way more than what you say. Your overview is a gross simplification at best. You seem to be forgetting the input layer, RandR, dga, drivers, etc.
Not only that, the X11 protocol is what allows remote deskstops and so on. Plus it has been a standard for many years and is what part of what makes it so portable across all platforms (even Windows).
Edited 2007-08-10 13:14
Yes, of course it’s a simplification. X do all the interconnections between the different layers, so there is a lot of things behind the scene.
But the fact is that, when using beryl, the render+clipping+compositing is not done by X.
If you add the fact that QT will do the widget drawing, then X behaves more like a “middleware”.
The X11 protocol is great for remote “x-clients” connecting to your local “x-server”. Is that really the same that a “remote desktop” ?
Yet, at the same time, the Windows remote desktop is vastly superior so that cannot be used as a very good argument anymore.
vastly superior? you have no clue what you are talking about..
first off, its doing really very different things.. compare RDP to vnc or NX(where NX totally beats RDP to death btw..).
and second off.. nah, you probably wouldnt understand, so ill not waste my time arguing with you.. but if you really really wanna know, go look up what its really about, or request it here, and i might enlighten you..
“Not only that, the X11 protocol is what allows remote deskstops and so on.”
Does this mean that Qt 4 apps won’t be able to be displayed in remote X sessions anymore?
No. It should have no effect on that the way they are doing it.
> Today, the X11 “core” is not bound to any card-level graphic language.
> And AFAIK, Xegl will not be a compositing engine.
OpenGL is hardly a “card-level” graphic language. In fact, it is very close to being a superset of X11 (not formally, but in principle), basically bringing 3d rendering and some nice effects to the table. Even network abstraction is a basic feature of OpenGL. Bringing them together raises a lot of formal objections (APIs would change), but no change in philosophy.
Uh, who does all the resource management, input handling, etc? Beryl is just a compositing manager — it composes together functionality that’s mostly implemented in the X server or GL stack.
You can’t “kill” X11, it’s the resource manager, handles the events, links the rest of it together. What you mean is minimising it to a tiny component as in Xegl: This is a long term goal of the X server.
I was wondering what toolkit to use. To be honest I was really unsure, but finally I bought a GTK+ book. Now I am not so sure anymore. This flickering has been something I have been annoyed at for years, and pretty much makes QT superior with a great margin…if it works that is
You bought a GTK+ book? And the only reason to switch to Qt is this flicker stuff? How about API? The API of Qt is way, WAY ahead of the GTK+ one…. That is if you like C++ 😉
you can write Qt apps in python, ruby or java (to name three) so the “if you like C++” is really a non sequitur =)
that said, i completely agree that a better reason to pick between the toolkits is API design (for me this includes consistency, clarity, speed in use and documentation) which is a place where Qt has always shined brightly.
Aaron, don’t get me wrong. I ‘like’ C++. And Qt simply rocks. At work we use the commercial license of Qt on a daily basis, and I often refer to them as API fetishists 🙂
I would really, really want us to make our own API’s as the ones from the Trollies.
For programming C++, Qt is a toolkit that aims at making your programming easier. Gtkmm (the C++ layer of GTK) is a big mess to me compared to Qt, because of horrible docs , and very complex, barely documented APIs using templates. Still though, I think the signals system in Gtkmm (libsigc++) is much nicer than Qt Signals (argument binding is extremely useful) and doesn’t need a preprocessor.
Buy a book? You don’t need no stinkin book with Qt! Complete and clear docs are standard.
Anyone else here impressed by the use of videos to explain what the flickering problem is, and to demonstrate the fix
I can’t count the number of times an article is written; especially on tech sites; and they ramble on and on about problems, but never demonstrate it.
In any case, looks like a great job, though like others have said, I wonder what the limitation is in X that causes this?
Why is it that OS X’s Aqua windows tend to move extremely quickly when you move them around?
I mean, they have their Quartz Extreme and X11 has Compiz, so they’re both hardware accelerated with OpenGL, but even then, Quartz seems to redraw windows much better when you move them, even on video.
http://www.youtube.com/watch?v=HCY5Y4fmbx4
http://www.youtube.com/watch?v=b1iSIkyiAVk
I don’t know what it is, if it’s Core Image or their imaging model. Will Cairo bring this to X11, or is it just something that they haven’t figured out yet?
Afaik, most of that stuff is done by Arthur on linux (Qt rendering engine), and maybe the Quasar library for image effects which should be in KDE 4.1…
I don’t know. Is it just me or does it feel like QT hacks around a lot of problems instead of fixing them properly in Xorg and drivers etc so everyone benefits, not just QT?
As an example, look at what Carl Worth & co are doing to optimize Cairo in recent months (http://cworth.org/blog/). When finding bottlenecks, instead of just hacking around them, they are fixed properly and all rendering stacks on top of Xorg benefits (including QT).
Edited 2007-08-10 15:41
The problem is that this “hack” fixes things on Windows and OSX as well, so even if they did fix X11 they still would have had to done this work anyway. So while it would be nice if they could contribute to X as well I can understand why they don’t want to get too involved in fixing 3rd party code when it wouldn’t reduce their workload and they’ve got plenty of work to do on their own products.
Is it just me or does it feel like QT hacks around a lot of problems instead of fixing them properly in Xorg and drivers etc so everyone benefits, not just QT?
It’s just you. Trolltech employs Zack Rusin, who has done a lot of work on Xorg and other projects that are outside Qt. EXA and the new Render implementation for example were Zack’s work. I don’t know enough about it to tell you whether it would have even been possible to fix this particular problem in any other way.
EXA was adapted from KAA. Zack was one of the adapters. I don’t think Zack has contributed anything more worth mentioning to the Xserver (not after a quick look at the git log anyway). Don’t know about other projects, but I do know that Zack is a great hacker (not to belittle his contributions).
But yeah, I would like to see more stuff like this from Trolltech. Fixing things the right way ™ instead of cludges in QT.
Trolltech is more than enough of a real FOSS company to fix things the Right Way (TM) whenever feasible, so I suspect this must have been particularly hard or even impossible to fix due to X’ architecture. If I understood some ppl above in this discussion, GTK already does something similar.
If that is so, X is apparently broken beyond repair. Sad.
well, it might just be a lot of deep, architectural work to get it fixed. And commercial entities rarely go for big, architectural rewrites. They go for visible features in a reasonable timeframe… It’s one of the advantages we as a FOSS community have – we have people who don’t care they need to start a project which will take years and which will only show results in a indirect way. If it’s really a deep architectural problem, the community will need to start the work on it, I’m afraid.
Or he could be referring to Glucose, which is a very different (and much simpler) approach: create a new 2D X11 driver that calls into the DRI using glitz. Most of the technical issues making that difficult were solved when the indirect accelerated rendering support was added.
Where has QT been hacking around anything? The GTK+ developers have talked about childless windows for a long while now, too. It’s actually pretty important to do that if you want to get in-window compositing without depending on a compositing manager. Plus it reduces X pixmap memory usage.
Yes, it is. You don’t understand what a compositing manager does. All it is responsible for is the end-result drawing of windows, the structure of which are provided by the X server still. The client still send drawing commands to X, which still is responsible for clipping them into their respective windows, and which is still responsible for managing input. The most basic compositing manager actually does nothing other than take the existing X-managed window positions and blit the window contents onto the screen based on that information.
The only way to “get rid of X” would be to merge most of X into your compositing manager, which is really just stupid on such a multitude of levels I don’t even know where to start enumerating them.
Contrary to all-so-popular belief, X is not a bottleneck. Removing it isn’t going to gain you anything, but it will cost you quite a bit.
Removing X is only something ever advocated by people who don’t know what the heck they’re talking about, as every argument against X can be pretty easily shot down by anyone with even a smidgen of understanding on how the X infrastructure works.
Do you know if Glucose ever went anywhere? I never saw a mention of it after the initial announcement from Zack.
Alan Hourihane has picked up the torch and created a glucouse-2 branch. Last I heard of it was in this mail to the xorg mailing list:
http://lists.freedesktop.org/archives/xorg/2007-March/022928.html
How funny is this. Just a month ago I rewrote my fpGUI (Free Pascal GUI Toolkit) which was based on a windowless framework to being a windowed framework. My experience was the opposite.
My event handling and redrawing was a nightmare with the windless design. The code is now much cleaner and performance is much better using the windowed (every widget has a window handle) design.
Going windowless, you have to handle more events, distribute events, handle window clipping, etc… A lot more work, considering the underlying windowing system can handle all of that for you! I do agree on the fact that a windowless design is more lightweight, but allocating resources on todays systems are not a issue anymore like they used to be years ago.
For more info on fpGUI go to http://opensoft.homeip.net/fpgui/
My 2c worth.
Well, I can imagine it is a lot to handle all events yourself, esp if you write your own GUI at home. But Trolltech has more resources, and the performance improvement is imho a lot more substantial than you suggest. Just look at those movies… Or compare a linux gui with a windows gui. The latter is a lot more smooth when resizing stuff, even when run in wine.
I had always assumed that the cause of this “flicker” was layout management. But this fix indicates that the cause is actually one step lower, in that all size changes occur to X11 windows, which involves the propagation of numerous events.
I don’t think it’s X11, but rather “dumb” toolkits that draw way too often. Take a look at FOX toolkit (www.fox-toolkit.org). It doesn’t do double-buffering except maybe for one or two widgets. Neither does it have windowless child widgets. Yet still the performance is absolutely great. This is mainly due to the delayed repaint/layout, which makes all the difference. Drawing in general is very expensive so you really only want to draw when absolutely necessary. See the “Delayed Repaint/Layout” section on the bottom of this page:
http://fox-toolkit.org/guiupdate.html
I just wonder if people commenting on this thread are actually reading some of the better comments around here. Those of you talking about X being the main bottleneck haven’t got a clue what you’re talking about. In reality, X does very little, which is the way it was designed (it didn’t specify a toolkit for a reason). The bottlenecks are elsewhere, and the biggest is how the toolkit manages this and what it pushed to the X server. Motif didn’t seem to have this problem, as ugly as it looked and as bad to program as it was.
Options such as creating a new, separate, and incompatible, X server are just so stupid it isn’t believable. This isn’t going to be helped in X for some time, and even then, the biggest bottleneck is still how the toolkit goes about doing things. XCB, as I understand it, is a layer below Xlib, so doing various things directly with XCB can speed things up (and Trolltech may already be doing it), but it’s not a panacea.
Apparently, if Trolltech fixes an awful lot of things in Qt then they’re doing it all wrong because they should be fixing things in X. What an absolute load. What do you expect them to fix? Also, you have to take into account that this has to benefit cross-platform as well. If Trolltech does all it can to alleviate problems in Qt, and other parts of a system are improved along with it, then we should be in for a substantial improvement, shouldn’t we?
I don’t know what it is, but all this ‘fix it in X’ stuff just sounds like some thinly veiled explanation as to why GTK, and Gnome, is just so particularly bad on this front. Attempting to solve this with Compiz, or relying on hardware acceleration to minimise the effect, simply isn’t any solution at all and really is a ‘hack’.
Motif didn’t seem to have this problem, as ugly as it looked and as bad to program as it was.
Interestingly Motif has both widgets with windows and without, ie. Widgets and Gadgets.