slosser@ntsc-rd.navy.MIL ("Steve Slosser") (05/14/91)
I have heard that the event-driven nature of the X Window System makes it unsuitable for real time graphics applications. Has anybody had any experience in this area that would support or dispute this claim? -- Steve No disclaimer. No cute quote.
dsr@mitre.org (Douglas S. Rand) (05/14/91)
In article <824E719F0020153E@TWNCU865.BITNET> T441613@TWNCU865.BITNET writes:
I know many good features about X Window. But I don't know what is its bad
features. And I want to know what X window will be in the future. Can anyone
tell me answers or discuss about it.
Thanks.
Michael Lin
There are plenty of bad features. IMHO (and I'm sure someone will
correct my mistakes) X was never intended to solve all problems for
people with specific needs in the graphics arena. X is more of a
virtual terminal protocol with some graphics thrown in, kind of a
networked Suntools (forgive me).
Here's a few of my FWL (Frequently Wished List) along with what
little I know about solutions:
1) No scalable graphics or fonts (but scalable fonts in R5). Packages
which run on top of X can supply this (InterViews, ULGKS, Phigs, etc.)
2) Lacks 3-D handling. The Phigs Extension to X (PEX) does fill this
void as well as creating other problems.
3) No image processing capability. This includes poor handling of
images and image compression. Some are working on an X Image Extension
to deal with this area.
4) Real pain in producing WYSIWYG products since the rendering in
X is unrelated to rendering on a printer. Display Postscript can
answer this in the X world or one can always use NeWS ( ;^) ).
5) Smooth animation and timing are all a b*tch. Some work is being
done in this area and a standard extension supporting double buffering
are already out as part of R4.
I'm sure you'll get more comments.
--
Douglas S. Rand
Internet: <dsrand@mitre.org>
Snail: MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJmouse@lightning.mcrcim.mcgill.EDU (der Mouse) (05/16/91)
> I have heard that the event-driven nature of the X Window System > makes it unsuitable for real time graphics applications. Has anybody > had any experience in this area that would support or dispute this > claim? X is generally unsuitable for time-critical operations. But the reason has little to nothing to do with its event-driven nature; the reason is simply that by the nature of the spec, it cannot make timing promises. Someone may have created an implementation that promises useful time bounds, and such a version may be of use for time-critical applications. But I know of no such. And in any case, this does not imply that it is unusable in real-time applications, only that the real-time part must not depend on X. For that matter, most UNIX systems (UNIX being, in some sense, the "native" operating system for X) are badly suited to real-time work; I know, I was involved in building the operating system interface for a robot control system with a 28-millisecond cycle time. But there is absolutely nothing wrong with using X in non-time-critical parts of real-time applications, any more than there is anything wrong with using stdio, or curses, or any other such library. The same cautions apply, but that's all. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
tjt@cbnewsh.att.com (timothy.j.thompson) (05/16/91)
From article <9105160040.AA05160@lightning.McRCIM.McGill.EDU>, by mouse@lightning.mcrcim.mcgill.EDU (der Mouse): > And in any case, this does not imply that it is unusable in real-time > applications, only that the real-time part must not depend on X. For > that matter, most UNIX systems (UNIX being, in some sense, the "native" > operating system for X) are badly suited to real-time work; I know, I > was involved in building the operating system interface for a robot > control system with a 28-millisecond cycle time. This advice is certainly the safest and best in general. The situation is changing, though, for some realtime applications. For several years, I've been using UNIX and X Windows for a "realtime" application with a 10-millisecond "requirement", and have been quite happy. The application is MIDI, and graphics (e.g. flashing notes as they play) can be done in realtime without audibly affecting the timing. (This is on a 20 Mhz 386.) There are of course limits - there will always be limits. With System V Release 4, realtime performance can even be "guaranteed", by using the realtime scheduling class. To *recommend* this setup to people who would not normally consider UNIX for other reasons (e.g. because they want email, familiarity, etc.) is to invite complaints, though. I can only say that it works for me (and a handful of other people who use it as their only MIDI sequencer), and demonstrate it (e.g. at the upcoming USENIX). ...Tim...tjt@blink.att.com...