OSNews

GTK+'s redraw is actually fairly well-optimized. It's just optimized for the wrong thing. GTK+ has a habit of trying to batch and coalesce EXPOSE events. This cuts down on overall CPU usage, but increases latency, leading to visible redraw.

Of course, ultimately, a composited desktop is the only correct solution to the redraw problem. It also has the advantage of allowing the toolkit to optimize for minimal CPU usage, since the compositor ensures that redraw latency (with reasonable bounds), doesn't result in visible artifacts.

I like efficiency over low latency .

Compositing doesn't help when you switch desktop...

i don't think this will ever be fixed, they'll just implement an open gl x server to get around it, rather than fix the gtk slowness.

It's sad, but that's what I think they'll do as well. It's also sad in that you're going to need hardware acceleration to really take advantage of a fully OpenGL powered X server. This isn't what desktop Linux was supposed to be about.

What will probably happen is they'll get around the problem in one way, but the problems will probably manifest themselves in another area.

"as for gnome's redraw speed - it's truely a disgrace. try with a xinerama set up and drag one window from one desktop to another, and you'll see how bad things can be. i don't think this will ever be fixed, they'll just implement an open gl x server to get around it, rather than fix the gtk slowness."

Haha, you mean like what OS X did with 10.2 !
----

As far Ubuntu's slow boot time -- go smoke a cigar.
It has less to do with Linux itself but rather Ubuntu.

If you want a fair comparison go waste a couple of hours installing Gentoo and then boot from that.

Since you're compiling everything you have vs everything you could have you'll get an Apple effect. The same goes for services.

Ubuntu is marginally slower than Windows XP to boot, but it's nothing painful. For me at least. Maybe a minute.

Edited 2006-06-04 19:08

I definitely agree with the GTK redraw problem. For me personally, that has been my number one complaint for the last 2 or 3 years about using Linux on the Desktop.

Here is an old video I made to demonstrate the problem. I don't think the problem is really any better than it use to be, but it's not as much of a problem for me these days because I don't use Gnome at all any more. I just use Openbox and rox-filer. I still notice sluggish redrawing, but it's not nearly as bad with general GTK apps as it is with Gnome+GTK apps.

http://www.davidcourtney.org/Files/Win-vs-Lin-video.asf

(Sorry that I only have an asf file. Video encoding isn't my thing.)

Here is another interesting video. I didn't make it ... I don't know who did. But this is the kind of ultra fast response time I dream about.

http://www.davidcourtney.org/Files/AmigaOS4-Fast.avi

I have Zeta installed on a spare machine ... one thing I really like about Zeta is how fast everything is. Navigating the file system, resizing windows, etc... It's all very responsive. The only slow thing about Zeta is when you draw your mouse cursor accross the desktop background as if you wanted to highlight multiple icons. For some reason, that single thing is *extremely* slow. I suspect it has to do with the fact that Zeta draws some kind of tranlucent window over the icons. They should get rid of the "special effect" and just use an ordinary line border.

http://www.davidcourtney.org/Files/Win-vs-Lin-video.asf

(Sorry that I only have an asf file. Video encoding isn't my thing.)

I'm not saying that GTK's redraw speed couldn't be better -- it definitely could -- but that video is pretty unfair.

In the Windows case, the window is on top of a blank desktop with a few icons on it -- it doesn't even have to redraw any wallpaper. On the other hand, in the Linux case you've got a Nautilus window on top of Firefox. For whatever reason, Firefox's drawing speed under Linux is extremely poor (open a page with some Flash images -- the Flash parts of the page are always displayed first). This is certainly something that needs fixing, but it's not the responsibility of the Gnome project, or even GTK, but instead the Mozilla/Gecko people.

A fairer comparison would be to move/resize a Nautilus window on top of a plain Gnome desktop, without wallpaper, exactly as you had in Windows.

I have Zeta installed on a spare machine ... one thing I really like about Zeta is how fast everything is. Navigating the file system, resizing windows, etc... It's all very responsive. The only slow thing about Zeta is when you draw your mouse cursor accross the desktop background as if you wanted to highlight multiple icons. For some reason, that single thing is *extremely* slow. I suspect it has to do with the fact that Zeta draws some kind of tranlucent window over the icons. They should get rid of the "special effect" and just use an ordinary line border.


That's an option in Preferences, Tracker.

Boot problem is not related to kernel - as the author of review states. Kernel boots in few seconds.

It's related to various services, often waiting for timeouts to happen or interfaces to respond (especially network ones!), or which are generally slow and unoptimized. They are the bottleneck.

Possible solutions:

Some services could be executed after the GUI is up.
(printing, mail check, ,even network in cases user is locally authenticating, etc.)


Other way is to use something as init-ng which will parallelize execution of init scripts. Some people argued that this isn't a proper to improve boot time, so instead services should be improved to be faster, but I don't agree.

For example, if you have IO intensive service and CPU intensive service running at the same time, system is more efficiently utilized than if they run in non-parallel way. Also if you wait for a network response, you could in the meantime run other processes. So generally it is faster with parallelization (probably even more on SMP machines).

Some services could be executed after the GUI is up.
(printing, mail check, ,even network in cases user is locally authenticating, etc.)

Hence the concept of early-login (currently on hold due to networking issue).
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952

That method allows to directly go to the login screen while booting services. When the bugs will be ironed out, expect it to be available on Fedora Core first due to its cuttier technologies.

well you are more than welcome to fix any bug/problem that you see and if it really exists I am sure that your help would be greatly appreciated. As for the redrawal speed there are a lot of things that can cause problems and it's not necessarily a gtk specific issue.