In article <93vcv1$8c7$1@inn.qnx.com>,
Mats Byggmastar <mats.byggmastar@mulfi.NOJUNK.fi> wrote:
The disk space and memory requirements of the X
environment, no shared memory extension, no optimized
local transport mechanism, and no grafx acceleration.
What is “optimized local transport mechanism” ?
Xphoton only support TCP connections. The QNX4 X servers
accepted a QNX Send/Receive/Reply transport as well.
And why no grafx acceleration???
The majority of the drawing code in Xphoton was written
before Photon 2 existed, ie. it was written for Photon 1.1x.
Mapping the large number of X drawing primitives to the
relatively small number of Photon drawing primitives
gives something like,
one X draw → (up to) 3 Photon draws
Additionally, since Xphoton doesn’t have direct access to the
grafx card memory (it may not even be on the same machine)
any X raster operation that includes the destination pixels
will take a lot longer.
yes, but this would be true for any X application on
any system. I would have assumed that mapping between
different drawing protocols/functions/whatever would
not add an extreme overhed compared to the actual drawing
oeration itself.
No. XFree86 on Linux talks directly to your grafx card,
the driver for the card is part of the X server. It can
directly access video memory if it wants to, for example,
XOR an image onto the screen. Fonts can be rendered directly
into offscreen memory,…
It feels a bit funny, that my Qt application running on
a RTP machine, is much snappier (and with no errors) when
the $DISPLAY is exported over the network to a Linux XFree86
machine or even to a Windows 98 machine running X-Win32, than
running locally with Xphoton.
qt → tcp → linux X <-> hardware
vs
qt → tcp → Xphoton <-> Photon <-> photon grafx driver <-> hardware
If the X-Win32 is the cygnus one, it simply opens a directdraw
surface and it has direct access to the pixels. Communication
with the underlying windowing system is handled automatically,
it effectively thinks of the dd surface as its screen
qt → tcp → X-Win32 <-> directdraw surface
But lets not get cought up in the speed issues. I can live
with quite slow updates, as long as it is bug-free.
I do have some ideas (but never enough time) to speed Xphoton…
See the separate post ‘Xphoton bugs’.
…trying to fix the bugs first.
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.