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,
too.
>
> <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
unnecessary.
>
> 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: