Very Computer

What are the lessons we can learn from QNX Photon?

L S Ng

How does QNX Photon do it?

L S Ng

Quote:>It is possible to slim down X, to make it run faster and requires less
>memory?

Also, let's not forget that programs that are frugal with memory don't
necessarily use the best algorithms.

The memory usage of X also could also depend on which vendor's X you use.

I'd say, just get more RAM.

Quote:>What are the lessons we can learn from QNX Photon?

Liang> It is possible to slim down X, to make it run faster and
Liang> requires less memory?

Liang> What are the lessons we can learn from QNX Photon?

I've been thinking about this as well. X is just too big. I've never
seen or touched QNX, so my opinions on it are rather vague, but from
what I gather they get speed and small size just by cutting out as
much of the extraneous stuff as they can. The X protocol is filled
with lots of special cases that have to be dealt with, optimized away,
etc. Most of the cruft comes from being designed when X terminals were
much different than they are now, and X was designed to accomodate as
many of the different vendor designs as possible. Thus, an X server
has to be able to handle both bit-plane and frame-buffer memory
organizations, in both big-endian and little-endian order, with
several different types of pixel color assignments. To reduce the
network usage, they also added many complicated drawing methods like
wide, dashed, ellipse and filled, self-intersecting polygon drawing.
Thus, an X server has to be a fairly complicated piece of code. This
adds up to lots of memory. I don't think much can be done to fix this
while still keeping the few good points of X. The ability to grab X
client source code from 1988, compile it, and have it run with few
difficulties is not something to be scoffed at.

For those interested, I've read that AT&T's new 'plan 9' OS has a
graphics interface consisting of something like 10k lines of
code. It'll be interesting to see how this fares against X.

--

                      .oO finger for PGP key Oo.

Quote:>How can X be slimmed down, to make it run faster on less memory?

>How does QNX Photon do it?

--

http://www.qnx.com/~danh                    175 Terence Matthews
phone: (613) 591-0931 (voice)               Kanata, Ontario, Canada
       (613) 591-3579 (fax)                 K2M 1W8

: What are the lessons we can learn from QNX Photon?

Never used QNX, so I can't say there, but a few ideas spring to mind:
Cut the number of colors to under 256 (8bpp)
Cut the size of the virtual desktop (but this may only use video mem)
If you're using fvwm, cut out some of the extra features (virtual windows, etc)
Run in a smaller video resoltion (800x600)

--

"Sure we should sell California to the Japanese.  It's going to fall into
the ocean anyway." - Car Talk (on NPR)

Quote:>It is possible to slim down X, to make it run faster and requires less
>memory?

But there are alternatives.  mgr is availible.

Gnustep is working on re-implimenting OpenStep (aka NeXTStep)  on top
of X, but they are eventually planning to us Ghostscript to go with
a display postscript base.

Also, 8 1/2, plan 9's windowing system is incredibally lean, mean, fast,
etc etc.  It lacks clicky icons and lots of other stupid Windowing junk,
so the majority of the lusers out there will hate it, but who cares.
("Brazil", the follow on to 8 1/2 also looks interesting.  They are planning
to reduce graphic operations down to blocks of pixels to easily integrate
TV and such)

Quote:>What are the lessons we can learn from QNX Photon?

--

Disclaimer:  It was another country, and besides, the wench is dead.

Quote:>It is possible to slim down X, to make it run faster and requires less
>memory?

Find the highest level, most abstract X interfaces you want to
support, and then re-implement it from scratch providing those
interfaces.  Want to be able to download and compile X programs, with
no worry about networking?  Then*the networking code, just
create a purely local streamlined app and series of libraries that
gives you the same basic functionality with the same API.  Also*
optional things, just do the bare minimum required.

Want the networking support to work?  Get a document that specifies
the raw X network protocol.  Then implement as server for it, from
scratch, hand tuned to a particular OS and hardware platform.

These would really, really streamline X.  They'd also probably be
really difficult, and nonportable.  They'd also be obsolete the moment
the next version of X comes out.  Worth it?

I hope something better comes along within 20 years or so.
--

Quote:>I've been thinking about this as well. X is just too big. I've never
>seen or touched QNX, so my opinions on it are rather vague, but from
>what I gather they get speed and small size just by cutting out as
>much of the extraneous stuff as they can. The X protocol is filled
>with lots of special cases that have to be dealt with, optimized away,
>etc. Most of the cruft comes from being designed when X terminals were
>much different than they are now, and X was designed to accomodate as
>many of the different vendor designs as possible. Thus, an X server
>has to be able to handle both bit-plane and frame-buffer memory
>organizations, in both big-endian and little-endian order, with
>several different types of pixel color assignments. To reduce the
>network usage, they also added many complicated drawing methods like
>wide, dashed, ellipse and filled, self-intersecting polygon drawing.
>Thus, an X server has to be a fairly complicated piece of code. This
>adds up to lots of memory. I don't think much can be done to fix this
>while still keeping the few good points of X. The ability to grab X
>client source code from 1988, compile it, and have it run with few
>difficulties is not something to be scoffed at.

Almost every single add-on in the history of MS-Windows has been a
kludge. This explains away about 20% of the crashes. The rest, well...
you know who's fault that is... <g>

But, *please* don't fall into the compatibility trap... Especially since
the Linux user base contains so many people that can maintain code. <g>
It's not worth compromising the speed or stability of the system. I would
love it (and I'm sure other people would too) if Linux + X effectively
turned my 486 into a P6... :)

Of course, I don't use Linux yet, so all this is outsider babble... :>
--
_________________________________________________________
Robert Woodcock | Note: Your standard disclaimers apply. |

................| it can be quite a curse) - Plucky Duck |

Quote:> ("Brazil", the follow on to 8 1/2 also looks interesting.  They are planning
> to reduce graphic operations down to blocks of pixels to easily integrate
> TV and such)

Anselm
--

Filenames are only for people who can't remember where they put their files.
                                                           --- Tarjei T. Jensen

|> It is possible to slim down X, to make it run faster and requires less
|> memory?

It would probably (certainly) be possible to rewrite some parts of the X
server to make them more efficient.  In particular, it would be nice to
have the server use mmap/munmap to allocate/free memory for things such
as large pixmaps so that the process size of the server could shrink as
well as grow.

I do not think there is too much you can change from the configuration files
which will shrink the size of the server much.

Jim

Quote:> |> It is possible to slim down X, to make it run faster and requires less
> |> memory?
> It would probably (certainly) be possible to rewrite some parts of the X
> server to make them more efficient.  In particular, it would be nice to
> have the server use mmap/munmap to allocate/free memory for things such
> as large pixmaps so that the process size of the server could shrink as
> well as grow.

        #define UseInternalMalloc  YES

to your own "site.def" file and compile a new server...

Harald
--
All SCSI disks will from now on                     ___       _____
be required to send an email notice                0--,|    /OOOOOOO\
24 hours prior to complete hardware failure!      <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig,                                         \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik                              //  /     \\  \

: |> It is possible to slim down X, to make it run faster and requires less
: |> memory?

: It would probably (certainly) be possible to rewrite some parts of the X
: server to make them more efficient.  In particular, it would be nice to
: have the server use mmap/munmap to allocate/free memory for things such
: as large pixmaps so that the process size of the server could shrink as
: well as grow.

A copying garbage collecgor would help in this---and many other programs--too.

: I do not think there is too much you can change from the configuration files
: which will shrink the size of the server much.

: Jim

Quote:> For those interested, I've read that AT&T's new 'plan 9' OS has a
> graphics interface consisting of something like 10k lines of
> code. It'll be interesting to see how this fares against X.

If you want the clean and simple Plan 9 feel on Linux, you can get
ports of 9wm (a clone of the window manager), 9term (a clone of the
terminal emulator, which is actually built into the wm in the real
system) and sam (the editor), but they still sit on top of a big old X
server.

The internals of the plan 9 display system are *very* different to X, and
rely on some of the deeper secrets of the OS, particularly the control you
can have over the namespace as seen by processes -- the upshot of it is that
you can do wonderful things like run the window system remotely in a
*completely* transparent fashion -- you can even run the windowing system in
a window logged in elsewhere :-)

pete
--
Peter Fenelon - Research Associate - High Integrity Systems Engineering Group,
Dep't of Computer Science, University of York, York, YO1 5DD (+44 1904 433388)

Cheers, Terry Murphy