Re: A Gov Application Developer's Perspective - X Windows future? - typo correction

On Sun, 23 Mar 2003, Jim Schatzman wrote:

>
> 2) Performance/Windows implementations - The current Cygwin port of XFree86 is incredibly slow. Our benchmarks
> show that it runs something like 10x slower than commercial X servers for Windows. Like it or not, Windows
> is the platform of the future for analysts' desktops. We need the highest possible quality of graphics
> service on these machines.
>
> A start might be an X Server written from the ground up to use native Windows GDI and DirectX
> functionality. Adequate OpenGL support has been around for Windows for some time.
> When are we going to have similar support for X?
>

The best way to make this happen is to sponsor developers to work on it.

> 3) Reliability/Web enablement - Yes, I am very familiar with Broadway, X Web, LBX, etc. None of this
> works in practice as well as what we need.   One problem is that web browsers
> make lousy window managers. Another problem is that web deployers generally want their applications
> to work on ANY CLIENT with ANY BROWSER. Until such time as X Windows is universally available
> as a built-in or plug-in for all major browsers and all versions of those browsers, browser compatibility
> is an issue. Java has a similar problem, mainly due to Microsoft's obstinacy, but we are getting to
> the point that Java works fairly well with IE, Netscape and Mozilla.  X Web has not yet achieved
> much general acceptance.
>
> I am also familiar with the major commercial replacements for X protocol: Citrix, Tarantella, GoGlobal.
> All largely solve the browser compatibility problem. There are some performance improvements here
> and some MAJOR PERFORMANCE HITS with these technologies. For example, Tarantella can run
> a factor of 10x to 100x slower than native X Windows technology.  For highly dynamic user interfaces,
> this is not an acceptable solution.
>

My impression is that you are saying that X is best for such things.

> 5) Reliability/Anachronisms - IMHO, the world would be better off if "color map" were to disappear from the
> community's vocabulary. Color maps and problems with X Windows fonts continue to plague
> deployers of X Windows applications.  This is ridiculous.

You don't have to support 8 bit displays in your application if you don't
want to. Many toolkits (gtk, Qt, Tcl/Tk) work easily with both 8 bit, 16
bit and 24 bit displays.

I am pretty sure the real reasons for continued use of 8 bit displays are

     * X terminals/thin clients which have limited amount of video memory
       and weak graphics chips. Hopefully this will go away by itself in
       the coming years

     * Binary only 8 bit applications that you are unable or do not want
       to upgrade. These should go away as well.. sooner or later.

>
> 6) Performance/Hardware acceleration - Absolutely any acceptable solution needs to fully support hardware
> acceleration. An ideal solution would support both offscreen hardware acceleration on the application
> side (X client) and onscreen hardware acceleration on the client side (X server). Some of this
> capability exists today, but it needs to work seamlessly and reliably on essentially all
> platforms before we can declare victory.

I really had no problems with hardware acceleration. The major hurdle for
such things are typically lack of available documentation for the chipset
- a large company can go a long way in helping this.

>
> 7) Development/maintenance costs - The numerous standard X APIs and extensions are so
> complex that development and maintenance costs are excessive. IMHO, X needs a serious
> house cleaning. Instead of demanding backwards compatibility, the old stuff should be
> gradually obsoleted and deleted. Face it, it is becoming tough to find X books anymore
> in the computer bookstores because the commercial and government worlds are both
> abandoning X for simpler APIs that are more easily applicable to the Web.

If you just want an "MFC"-like program - use one of the toolkits, like
Gtk, Qt or Tcl/Tk.

If you are bent on programming in native API - Xlib API is *very* good in
what it does. It is certainly a lot better than the mess Windows is.
Just make sure to think in terms of Xlib API, and not trying to translate
Windows code into X.

                     best regards

                        Vladimir Dergachev

>
> Thanks for reading my comments-
>
> Jim Schatzman
> Northrop Grumman Mission Systems
>
>