PTC for X documentation
Table of Contents
1. How to get the maximum out of PTC for X11
2. PTC's ways of addressing the screen in X11
2.1. Direct Graphics Access (DGA)
2.2. MIT Shared Memory Extension (MIT-Shm)
2.3. XImage
3. Options specific to the X version of PTC
3.1. Using Console::option
1. How to get the maximum out of PTC for X11
Here are a few short tips on how to get the maximum out of PTC for X11.
If you stick to all of them you can get a 100% speed increase (this is
NOT exaggerated!). The other way round, if you ignore them, you can lose
half the speed of your application.
-
For PCs with Linux: Use pgcc or egcs instead of gcc. With the realtime
tunnel, pgcc 1.0.3a with -O6 -mpentium gives a 40% speed increase over
gcc 2.7.2 ! If you have a pentium, then you should use a compiler that
can optimise for it.
-
For PCs: Don't be lazy. Download NASM so you compile the assembler
routines into PTC. They can give up to 50% speedup over pgcc even, so that's
definitely worth it.
-
For all platforms: Use 32 bit surfaces and let PTC do the conversion.
Don't be afraid of using them, the conversion routines will convert them
really quickly anyway and you get to write dwords into them. Alternatively,
use 16 bit surfaces for an additional marginal speed up. Avoid using
24 bit surfaces or surfaces with non-standard bitmasks!
-
For PCs with Linux: Warn the users of your application to put
proper video modes into XF86Config (e.g. "320x200") so your application
can use DGA mode. This will give at least 30% speedup over windowed display.
Alternatively, pass the pedantic DGA option so PTC will try harder
to initialise DGA.
-
Finally, instruct people to keep their system load down when running your
binaries, most graphics code doesn't like it when you compile a kernel
in the background..
2. PTC's ways of addressing the screen in X11
PTC at the moment implements three different ways of accessing the screen
which are totally transparent to you, the programmer (i.e. you don't have
to worry which one is selected when you write your code). Before I explain
what they mean, here is the order in which they are tried at runtime, the
ones which are tried first are given priority because they are faster.
The different modes will be tried in the following order:
-
Direct Graphics Access(DGA)
-
Shared Memory (MIT-Shm)
-
XImage
There are several reasons why DGA and MIT Shm can fail to initialise properly,
and these will be presented in the respective sections. Again, the policy
is to try the faster access modes first.
2.1. Direct Graphics Access(DGA)
DGA is an extension to the X protocol found, amongst others, in XFree86
servers. It allows direct writes to the frame buffer and thus it is quite
fast. It is also the only way to get fullscreen access in X apart from
stretching, which we really don't want ;)
For these reasons, PTC will try to open a DGA mode first. Due to the
nature of DGA there are however quite a few restrictions:
-
Your X server has to have the DGA extension and the VidMode extension (both
are present in XFree86) AND
-
Your application has to run as root, or has to be setuid root AND
-
The video mode you request has to have an entry in the X server config
of the target machine (e.g. in XF86Config: Modes "800x600" "320x200") -
unless you force DGA - AND
-
You must not use remote display, i.e. display a window from a remote machine.
All of these restrictions are due to the nature of the DGA extension, not
to the way PTC is implemented. If you can't meet one of them, PTC will
automatically fall back to the next lower level, which is MITShm.
2.2. MIT Shared Memory Extension (MIT-Shm)
This X server extension, present in most X servers (tested on SGI, Linux)
on systems with shared memory capabilities allows PTC to store its images
in a shared memory segment and to skip the Xlib IPC channel.
This is not much slower than DGA, maybe a tiny bit because the surface
you use has to be copied twice (once to the image, then to the window),
but of course it is not fullscreen. Then again, your application does not
have to run with root permissions.
The only restriction of SHM is that it will not run over a network.
For remote display, only the next method is applicable.
2.3. XImage
The last option in the chain. This is certainly much slower than the ones
mentioned above. A normal XImage is created as an offscreen surface to
draw into and is put into the window when update is called.
The already mentioned advantages: No access right restrictions and it
runs over a network (which is quite slow for realtime graphics, but
this is about the concept :). Don't worry, though, this mode won't
be entered on too many occasions at today's standard of X servers.
3. Options specific to the X version of PTC
Contrary to what's mentioned above, PTC is not completely transparent
across all platforms. You do have control to some degree, otherwise it
just wouldn't be flexible enough.
First of all, you can choose between a couple of Console::open routines
that will allow you to do different things:
- Console::open(const char title[],int width,int height,const Format
&format)
This is the standard routine. If will try and open a console of size
width*height. First in DGA mode, then in MIT-Shm mode and then in XImage
mode.
- Console::open(Display *disp,int screen,Window w,const Format &format)
Your next option. Suppose you already have a window open in your
application and just want PTC to render into it. Pass your display
pointer, your screen and the window - and of course the format you desire
- to this open routine. PTC can then be used to render into this window.
If you just want to draw into a part of your window, use the next routine.
- Console::open(Display *disp,int screen,Window window,const Format&
format,int x,int y,int w,int h)
Create your own window and then use this to instruct PTC to draw
into a part of that window. Nuff said.
Note that your window will be destroyed when PTC exits. Read
the options below carefully if you want to continue using a window when
PTC exists. Also look at the unix/ example.
3.1. Using Console::option
If you've used PTC X11 2.0.0 to 2.0.9 you might have noticed that
the flags() routine is gone. There is a routine called option now which
you can use to pass option strings to PTC. This allows PTC some more
platform independence because platforms that do not support specific strings
can just ignore them. PTC X11 will recognize the following:
-
console.option("dga off") - Instructs PTC not to try and
initialise DGA but rather to force a windowed mode.
-
console.option("dga pedantic init") - PTC will now try a bit
harder to initialise a DGA mode. In detail, PTC will try
to open any video mode, not just the one you requested and then centre
the picture (e.g you requested 320x200 but only 800x600 is available)
-
console.option("leave window open") - If you use an open routine
for an already open window and want to continue using that window after
closing PTC, use this option and it will leave your window intact
-
console.option("leave display open") - Again, if you use your own
window, pass this option to leave the display open after PTC exits.
This is vital, otherwise your program will crash. Normally you will use
this together with the previous option.
If you want an example now, just look into the unix/ example directory
and see what Window.cc does.