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

Re: [Desktop] What accounts on a machine?

On Monday 28 October 2002 11:28, emile@evbergen.xs4all.nl wrote:
> Hi,
> On Mon, Oct 28, 2002 at 10:34:39AM -0800, Matthew Tedder wrote:
> > X Windows is like postscript in the sense that it sends instructions
> > on how to build a screen.  This enables scaling, 3D, etc. etc. and
> > less potential band-width utilization.  How many bytes does it take to
> > send a string of text versus the bytes required for high color-depth
> > pixel grids?  This also allows for use of accelerated 3D on client
> > hardware.  Windows absolutely cannot provide these capabilities.
> That's all great, but apparently X's font support is limited enough to
> force an application such as, say, Mozilla, to do all font rendering
> client-side, sending text pixel-by-pixel over the X channel.

That depends on your X server.  The latest XFree86 is not the fastest 
available, but font anti-aliasing has recently improved to the point that I 
haven't seen any better...  Not on Windows and especially not on the iMac.

> 'Modern' toolkits like GTK+ and QT tend to work with X on a /very/
> low-level basis; they just request every event, including mouse
> movements, and do all rendering at the client side. Whether that's
> because they want to be 'cross-platform' or because X doesn't live up to
> its promises, or the toolkit developers just don't understand X well
> enough, I don't know.

Yes--X is largely a protocol.  It's mostly very low-level, except for key 
things.  Font rendering, for example, normally takes up a large part of GUI 
building CPU cycles.  The X server, sitting on the client machine, thus 
greatly reduces CPU load on the server. 

Furthermore, if you also run the Window manager on the client machine, 
performance is very dramatically further increased on the client machine.

The synergistic effects of running applications on the server also includes 
sharing program code, and only requiring separate data instances for each 
user using that same application.  This sharing is at the kernel level.  
Desktop componant architectures such as those in KDE (in particular) are 
greatly amplified in terms of sharing and performance.  

Believe me, OpenOffice boots slowly on Red Hat 8.  But the second and every 
user thereafter pops it up very quickly.  For some reason, on Mandrake, it 
seems about twice faster, even.

There are a variety of additional tweaks that noticeably, further improves 
performance on the client workstations.  Overall, these workstations are 
clearly more efficient to use than individual PCs, for common office 
automation tasks.  Obviously, there are draw-backs for certain other kinds of 
uses.  But for a general purpose business desktop, this model rocks.  I'm 
using $200 clients with $315 LCD screens with 850Mhz AMD processor, 512MB of 
RAM and 3 hard 60GB hard drives.  Over 70 simultaneous users actively user 
OpenOffice and the system isn't noticeably slower than with one 
user--actually a bit faster on a practical level.  The clients have 64MB of 
RAM, but workstation performance doens't degrade until you go LESS THAN 16MB.

> I do know that get sceptical of that 'X is so efficient' cheering when I
> see a random X application being dependent on freetype2. fs-xtt is
> supposed to take care of that!

On a practical level, I have no issues with fonts.  And as for Mozilla, in my 
case, I am running it locally on the client machines.  LTSP enables you to 
configure each client with whatever local apps it has the RAM to run locally 
(or over NFS--which is not so good).  Pheonix would probably work nicely, 

> <pipe dream>
> Looking back, it would have been great if X would have allowed a
> separate (widget) rendering server, just like it allows a separate font
> server and a separate window manager, making the X protocol more
> widget-oriented instead of pixel-oriented.

Since X doesn't render widgets at all, and it does support extension modules, 
why not just make a widget server for it?  Actually, LTSP makes that even 

> Just like the protocol between clients and window managers could evolve
> without affecting the X protocol or forcing every client to manage its
> own window decorations, the protocol between clients and widget server
> could have evolved to match modern GUI needs without obsoleting X or
> affecting older applications.
> A standard data protocol between applications and their widgets.
> Wouldn't it have been wonderful. Imagine switching between GTK+ and QT
> without even a recompile! As easy as switching window managers!

Errr...  that would disallow a lot of the flexibility that differentiates the 
two......such as signals and slots verses strictly event driven widgets.

However, a widget server using XMLGUI over Jabber-based webservices would 
revolutionize and render the web obsolete, in my opinion (So long as XML 
document formats are allowed within--which is a natural).

> </pipe dream>
> Cheers,
> Emile.

Matthew C. Tedder
SimpFlex Technologies, Inc.

Reply to: