[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Why does X need so much CPU power?

Neal Lippman wrote:
	Well, most replies to my posting have pinned the "blame" on KDE and
Gnome rather than X per se. I'll have to reinstall on the laptop and see
how it looks with a more minimal WM.

  I hope you're not reinstalling just to change the WM...

	This does still beg the question of how Win95/98/Me/NT, etc, managed to
provide a reasonable "desktop" when KDE/Gnome could not, however. It

both KDE and Gnome are under development, more effort is spent on having things actually working, adding/changing features etc. than on performance improvements.

as others said if you don't have resources to waste just use something else, there's number of other WMs. You can definitely have more eye candy per buck in X than you can have in windows (because you have different types of eye candy available). hey, sco unix had pretty good X back on 40MHz 386 (certainly a lot better than win 3.0 or 3.1 or whatever version was out in '90 - '91).

	From what little I know of X, I'd tend to agree that X is being
overtaxed supporting a desktop environment that it was never designed to
do. Aside from the present market penetration of X (which could also be
used to argue to stick with Windows instead of ever having adopted
Linux), what would be the obstacle (other than, of course, the
time/effort for development) for a new graphics paradigm to sit atop
Linux? [Yes, I know there'd be a lot of apps to redo and so forth as
well, although if there were a Gtk+ compatibility layer...)

X is GREAT. just because a particular combination of software/hardware doesn't work well (too slow) doesn't mean there's a need to throw out the baby with the...

that's not to say that X is perfect, far from it, but it's being worked on, it's very flexible and extensible and there is nothing better, at least now.

btw there's a relevant slashdot.org article about Xr/Cairo (Xr was renamed Cairo), you can read something about how they plan to make better support for eye candy (vectors instead of bitmaps, because vectors are cheaper to transfer, easier to scale)


Reply to: