future of X

future of X

Post by Mike Kondrato » Sun, 02 Aug 1998 04:00:00



Would it be possible for an X Window guru write up some type of a report
comparing MS GDI to X. What is so good about X, why is it better then
Windows NT graphical system. Why it is not a good idea to intergrate
graphics into the kernel. I really don't know much about these thinks.
If some one could explane it to me, I would really appriciate it.
What do you think will happen to X in future. From what I read, some
people love, the others hate it.
 
 
 

future of X

Post by Bernd Paysa » Fri, 07 Aug 1998 04:00:00



> Would it be possible for an X Window guru write up some type of a report
> comparing MS GDI to X. What is so good about X, why is it better then
> Windows NT graphical system.

First, X is a network transparent client/server graphical system. I.e.
you have one program, the X server running on the box in front of you,
and any program you start on any computer on the net can display
graphics on your screen. NT 5.0 is supposed to have something similary,
and there are add-ons to current NT's which do it more or less. But X is
designed as client/server windowing system, whereas GDI was designed as
desktop (single machine, not networked) graphical system.

There are some flaws in both systems. E.g. it is not allowed to map a
window into a bitmap, neither on X (where bitmaps are in all other
respects identical to windows - you can do many operations into a window
or a bitmap), nor in GDI (where bitmaps are even less orthogonal to
windows). X font handling is worse than GDI's font handling. The network
protocoll of X isn't well suited for low bandwidth connections.

X's code basis is more stable than GDI, thanks to the open source
development and also just because it's older, and therefore more mature.

Quote:> Why it is not a good idea to intergrate graphics into the kernel.

It's a sin against modularity. If you put everything into the kernel,
you get a huge, bloated kernel. Kernel bugs affect the system much worse
than user program bugs, so your kernel will be less stable.

X as implemented currently, actually does too much in user space. It
also contains the low-level graphic adapter driver. This requires to
access ports and map video memory, and therefore X (and other graphic
systems) has to be cooperative if you switch consoles. Therefore the GGI
effort was born, which puts a small abstraction layer into the kernel
(KGI).

Quote:> I really don't know much about these thinks.
> If some one could explane it to me, I would really appriciate it.
> What do you think will happen to X in future.

X is still state of the art (even M$ admits that remote displays are a
good idea ;-). The only threat from the technical side IMHO is Display
PostScript, because it does it right. Knuth wrote a language for
typesetting, Allman wrote a language for mail transfer, RMS used a
language for his editor, and PostScript is a language for graphics. X
just transfers low-level operations, and doesn't allow to build
abstraction layers on the server side (e.g. put the drawing operations
for your widget library into the server, and just transfer "I want a
push button at x,y,w,h, with string 'OK'").

Quote:> From what I read, some people love, the others hate it.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/

 
 
 

future of X

Post by Walter Rawdani » Sun, 09 Aug 1998 04:00:00




Quote:

> ...

> X is still state of the art (even M$ admits that remote displays are a
> good idea ;-). The only threat from the technical side IMHO is Display
> PostScript, because it does it right. Knuth wrote a language for
> typesetting, Allman wrote a language for mail transfer, RMS used a
> language for his editor, and PostScript is a language for graphics. X
> just transfers low-level operations, and doesn't allow to build
> abstraction layers on the server side (e.g. put the drawing operations
> for your widget library into the server, and just transfer "I want a
> push button at x,y,w,h, with string 'OK'").

> --
> Bernd Paysan
> "Late answers are wrong answers!"
> http://www.jwdt.com/~paysan/

There is only one problem with X as compared to MS windowing system ..
It is daaaamn slow !!!

I don't know if it is due to the fact that it was written in C ( where GDI
is mostly written in optimized Intel ASM )
or something else but the fact is that on the same machine, using the same
graphics card X is much slower and
less responsive than GDI.

Walter

 
 
 

future of X

Post by Tim Kelle » Mon, 10 Aug 1998 04:00:00



> There is only one problem with X as compared to MS windowing system ..
> It is daaaamn slow !!!

> I don't know if it is due to the fact that it was written in C ( where GDI
> is mostly written in optimized Intel ASM )
> or something else but the fact is that on the same machine, using the same
> graphics card X is much slower and
> less responsive than GDI.

You don't think this might have something to do with video driver
quality?

--
Tim Kelley

New Orleans, LA

 
 
 

future of X

Post by Joel Ston » Tue, 11 Aug 1998 04:00:00




> > There is only one problem with X as compared to MS windowing system ..
> > It is daaaamn slow !!!

> > I don't know if it is due to the fact that it was written in C ( where GDI
> > is mostly written in optimized Intel ASM )
> > or something else but the fact is that on the same machine, using the same
> > graphics card X is much slower and
> > less responsive than GDI.

> You don't think this might have something to do with video driver
> quality?

Yes, the driver has a lot to do with it.

I see a lot of instances where the dsplay is much more responsive under X11
than under windoze on the same machine, but I sometimes see cases where X is
slower, for instance with certain cheap ATI cards, or Tridents, where the
X performance has been painfully slow.

On the other hand, with Matrox Millenium and most Diamond cards, X11 is
extremely snappy, with performance about as good as it gets.

In some cases, the Xfree programmers simply can't get good specs on the cards,
so they simply use generic VESA programming modes, with boring, generic
performance. In these cases, users have found dramatic speedups by moving to a
commercial X server such as those from X-inside.

js

 
 
 

future of X

Post by Bernd Paysa » Tue, 11 Aug 1998 04:00:00



> There is only one problem with X as compared to MS windowing system ..
> It is daaaamn slow !!!

Really? I have a Matrox Millennium, and on some operations (polyline), X
is several times _faster_ than GDI. Maybe the unaccelerated code is a
bit slower (C compared with hand-coded self modifying assembly), but I
never saw any real difference.

The only thing X is slow is combined with a slow widget set such as
TCL/Tk, which is molasse-slow. Not X's fault, either.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/

 
 
 

future of X

Post by walte » Wed, 12 Aug 1998 04:00:00




> > There is only one problem with X as compared to MS windowing system ..
> > It is daaaamn slow !!!

> Really? I have a Matrox Millennium, and on some operations (polyline), X
> is several times _faster_ than GDI. Maybe the unaccelerated code is a
> bit slower (C compared with hand-coded self modifying assembly), but I
> never saw any real difference.

> The only thing X is slow is combined with a slow widget set such as
> TCL/Tk, which is molasse-slow. Not X's fault, either.

> --
> Bernd Paysan
> "Late answers are wrong answers!"
> http://www.jwdt.com/~paysan/

  Well, I am using Matrox Mystique which is supposed to be one of the
better supported cards
under XFree.
Using the same system I have tried comparing speed of bitblit operations
under X and GDI ( win95).
Under X I used XPutImage and XCopyArea versus CreateDibSection + BitBlit (
using identity palette) under GDI.
In both cases ( XPutImage and XCopyArea)  X was visibly slower. Em
I missing something ?? Is there any other (possibly
better ) way under X to display images ?

Walter

 
 
 

future of X

Post by Bernd Paysa » Thu, 13 Aug 1998 04:00:00



>   Well, I am using Matrox Mystique which is supposed to be one of the
> better supported cards
> under XFree.
> Using the same system I have tried comparing speed of bitblit operations
> under X and GDI ( win95).
> Under X I used XPutImage and XCopyArea versus CreateDibSection + BitBlit (
> using identity palette) under GDI.
> In both cases ( XPutImage and XCopyArea)  X was visibly slower. Em
> I missing something ?? Is there any other (possibly
> better ) way under X to display images ?

use XShmPutImage instead of XPutImage. XPutImage certainly _is_ slower
than BitBlit, because it has to transfer the image over the "network"
(local, but one copy, though).

XCopyArea can generate an expose event, and maybe that's slower. Change
the windows flag so that no expose event is generated. The real copying
operation should result in the same bit blit operation on the Matrox
chip.

You should certainly use the same resulution and depth for both tests.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/

 
 
 

1. Windows(NT) future? Linux's future?

Heres some facts:

NT is gaining more features that Linux has, and someday with have them:
(multiple concurrent users, Remote Display ...)

Linux is gaining more features that Windows(NT/95) has, and someday with
have them:
(easier GUI's, easier setup ..)

So they are both heading towards some middle.

So in the future you can choose between two OSs than do basically the
same thing.  One is FREE, One is M$. Hmm...

Then your grandkids ask you "You actually paid for an OS?"

Don Mahurin

2. Xconfigurator missing in RH 8.0

3. Future Domain SCSI Problem

4. Unix Programming FAQ (v1.37)

5. Possible changes to the FUTURE DOMAIN parts of seagate scsi driver.

6. Pioneer CD-ROM (DR-A24X)

7. FreeBSD's Future Harmed by Browser Emulation?

8. PacBell (SBC) DSL Installation

9. Future Domian SCSI PCI

10. ACL's in the future?

11. Future of processing on the Internet

12. need help with future domain tmc-845 scsi

13. Future Domain SCSI 841