Xphoton status?

QNX Newsgroups (Archives) qdn.public.qnxrtp.photon
1

Hi,

I am making a X application for QNX RTP using Qt.
I notice a lot of bugs in the Qt widget behavior
that probably is due to bugs in Xphoton. Especially
when running on SMP systems (even when starting
Xphoton with -noshmem).

I was counting on proper X support in RTP when we
chose to use it for our project. Currently the
situation looks a bit depressing… It is not even
usable to run a demonstration version of my
application.

Can we expect any major improvements of Xphoton
in the upcomming patch(es) ?



Mats

2

In article <93ngmu$gdg$1@inn.qnx.com>,
Mats Byggmastar <mats.byggmastar@mulfi.NOJUNK.fi> wrote:

Hi,

I am making a X application for QNX RTP using Qt.
I notice a lot of bugs in the Qt widget behavior
that probably is due to bugs in Xphoton. Especially
when running on SMP systems (even when starting
Xphoton with -noshmem).

I know about the smp/noshmem bug, but where did
you report the others

I was counting on proper X support in RTP when we
chose to use it for our project. Currently the

New projects should really be Photon apps.

Xphoton is going to make your program a LOT bigger and slower. The disk space and memory requirements of the X environment, no shared memory extension, no optimized local transport mechanism, and no grafx acceleration. It works great for displaying an existing X app in Photon, but new projects should really be Photon apps.

situation looks a bit depressing… It is not even
usable to run a demonstration version of my
application.

Can we expect any major improvements of Xphoton
in the upcomming patch(es) ?

Tell us what problems you’re having and we’ll try
to address them

Garry Turcotte (R&D)
QNX Software Systems, Ltd.

3

I know about the smp/noshmem bug, but where did
you report the others

I did not. So far I’ve done all my development on Linux and
just now and then tested a bit on RTP. The app will be cross
platform (RTP and Linux) where Linux would be the backup plan
if we can’t use RTP. We are trying to emigrate from Linux to
a RTOS.


I was counting on proper X support in RTP when we
chose to use it for our project. Currently the

New projects should really be Photon apps.

Well for me that would mean learning another GUI api
before I would become productive… Not really an
option as I see it.


Xphoton is going to make your program a LOT bigger and slower.

Size does not really matter as the app will run on
a standard PC.
Why slower?


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” ?
And why no grafx acceleration???


Tell us what problems you’re having and we’ll try
to address them

I will try to make a list of my observations. However, it will
be “Qt bugs” as I don’t look under the hood and check what
Qt is doing with X.


Mats

4

Garry Turcotte wrote:

In article <93ngmu$gdg$> 1@inn.qnx.com> >,
Mats Byggmastar <> mats.byggmastar@mulfi.NOJUNK.fi> > wrote:

Hi,

I am making a X application for QNX RTP using Qt.
I notice a lot of bugs in the Qt widget behavior
that probably is due to bugs in Xphoton.

It is due to bugs in Xphoton … test your application
under XFree86 3.3.6 and you will get the prove.

[…]

I was counting on proper X support in RTP when we
chose to use it for our project. Currently the

New projects should really be Photon apps.
ranting against my own software

Well, it would be nice if Photon could provide a library as neat as Qt.
So … I believe the only viable alternative for Mat is to use XFree86
natively. (Also the Qt designer works … )

I had similar problems when I looked for a stable development platform
which includes a proper working DDD. Now I’m using XFree86, icewm (Motif
theme), xftree from XFce as file manager (drag/drop), the HTML widget
from wxGTK as help viewer and GDE as the ‘pure man’s IDE’. DDD works
flawless …
XFree86 needs ~8MB less than a comparable Photon installation. It was a
big surprice for me.

XFree86 3.3.6 is easy to recompile …
if you have any questions send me a mail to: armin at steinhoff dot de.

Armin

5

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A5F7050.C6BAD665@web_.de…

XFree86 needs ~8MB less than a comparable Photon installation. It was a
big surprice for me.

Well, Porche Boxter is about twice more expensive than ‘comparable’ BMW Z3.
Which is almost twice more expensive than ‘comparable’ Mazda Miata. While
they might be ‘comparable’ to someone, there are differences which are
important to others.

If you want to make a point, be more specific about comparisions.

  • igor
6

Igor Kovalenko wrote:

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A5F7050.C6BAD665@web_.de…

XFree86 needs ~8MB less than a comparable Photon installation. It was a
big surprice for me.


Well, Porche Boxter is about twice more expensive than ‘comparable’ BMW Z3.
Which is almost twice more expensive than ‘comparable’ Mazda Miata. While
they might be ‘comparable’ to someone, there are differences which are
important to others.

Igor, you know that we are Citroen fans … so you should have
mentioned at least the C5 or 2CV.
[hey Edelhard, don’t worry, nothing against your RO 80 collection ;-]


Igor, as you asked to be more specific, just details of the comparison
done by Armin:

  1. XFree86 + icewm (+ desktop manager) + font server + 1 xterm
    no background picture.
  2. Photon + pterm,
    no background picture

The XFree86 configuration is stable running may be like the Mazda Miata
which you mentioned. Photon I would compare with the VW Buggy…

Cheers,
Jutta

7

In article <93nm1l$jfk$1@inn.qnx.com>,
Mats Byggmastar <mats.byggmastar@mulfi.NOJUNK.fi> wrote:

[snip]

Why slower?

I simply meant X apps using Xphoton to display in Photon
will be slower then native Photon or native X apps.

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.

Tell us what problems you’re having and we’ll try
to address them

I will try to make a list of my observations. However, it will
be “Qt bugs” as I don’t look under the hood and check what
Qt is doing with X.

Fair enough

–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.

8

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.

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.

But lets not get cought up in the speed issues. I can live
with quite slow updates, as long as it is bug-free.

See the separate post ‘Xphoton bugs’.


Mats

9

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. :slight_smile:

–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.