# Your First Chromium Run

Your first Chromium run will be something quite simple. One of the programs built during the compile of the Chromium system is called "fonttest" - you can go ahead and run it now. If everything is OK, you should see a window appear with a text message in it. This window is using the system's OpenGL - nothing Chromium-related has happened yet. To run this program using Chromium, you will need to follow these four steps (you'll need three shell windows open):

1. Set up your search path.

   The Chromium executable programs are located in cr/bin/ARCH. On Linux, for example, it'll be cr/bin/Linux. If you're using Unix you should edit your .cshrc or .bash or similar shell start-up file and add cr/bin/ARCH to the search path.

   If you don't do this you'll have to provide the full path to the crserver and crappfaker programs below.

2. Start the mothership.

   Components of any Chromium run will need to know what they are supposed to be doing. They get this information from the configuration mothership. The mothership is controlled by scripts written in the Python programming language. One such script is located in cr/mothership/configs/crdemo.conf.

   Change to the cr/mothership/configs directory, and type:

   python crdemo.conf fonttest

   The mothership will now be running, and you should see a message to that effect.

3. Start a Chromium server.

   In another window run:

   crserver

   That's all there is to it. The Chromium server will configure itself by asking questions to the mothership that you ran in step 1. The server will dispatch the incoming stream of commands to the first SPU hosted by the server (the Render SPU in this case). Note: previous versions of Chromium would open a window at this point.

4. Start the application.

   In a third window, start the Chromium "application faker". This is a loader program that will start another unmodified application and make sure that it finds the Chromium OpenGL shared library instead of the system's. Run:

   crappfaker

   Again, the faker (and the OpenGL DLL, and the SPU's loaded by the OpenGL DLL) will all configure themselves by asking questions of the mothership started in step 1.

Once the application starts, you should see two windows appear: the Render SPU window and the application window. The application window belongs to the fonttest program started by the application faker. As far as fonttest knows, it is rendering to that window. The Chromium OpenGL DLL intercepts all of fonttest's calls to OpenGL and sends them over the network (in this case, a TCP/IP connection to your local machine) to the Chromium server, where they are dispatched to the system.

The Chromium run you have just done corresponds to the following graph of nodes:

# Other Sample Configurations

The Chromium distribution includes many sample configurations to demonstrate the capabilities of Chromium. Here's a summary of the scripts found in mothership/configs.

- autodmx.conf - a demonstration of Chromium and DMX in autostart mode.

- blur.conf - another example of OpenGL command filtering. This one demontrates the motionblur SPU.

- cavetest[12].conf - demonstrations of non-planar tilesorting. See the comments in each file for details.

- crdemo.conf - this is the configuration described above. One application node is connected (via a pack or tilesort SPU) to one crserver node which has a render SPU.

- crut_*.conf - demonstrations of CRUT

- dmx.conf - a simple demonstration of DMX support.

- dump.conf - a simple demonstration of XXX support.

- filetest.conf - a simple demonstration of XXX support.

- local.conf - this configuration demonstrates OpenGL command filtering. A single application node has a hiddenline SPU and a render SPU. The hiddenline SPU manipulates the OpenGL command stream to render the demo program's geometry in an outline mode.

- multitilesort.conf - demonstration of a two-level tilesort configuration.

- muralreadback_full.conf - a simple demonstration of XXX support.

- noop.conf - a simple demonstration of noop SPU support.

- playback.conf - a simple demonstration of file support in crservers.

- psl_cmp.conf - a simple demonstration of parallel submission with sort-last rendering and zPix compression using the Zlib compression method.

- psl_ple.conf - a simple demonstration of parallel submission with sort-last rendering and zPix compression using the PLE compression method.

- psubmit_last.conf - a demonstration of sort-last parallel rendering. Two application nodes, each with a readback SPU, render part of the scene. The partial renderings are sent by pack SPUs to the final crserver node's render SPU where the images are Z-composited together. The demo can be modified to use more than two application instances.

- psubmit_first.conf - demonstration of combining tilesort (sort-first) with sort-last rendering. The two application nodes each render half the scene and use the tilesort SPU to send rendering commands to two crserver nodes.

- psubmit_bswap.conf - demonstration of sort-last rendering with the binaryswap SPU.

- psubmitn.conf - XXX with the binaryswap SPU.

- rbcmp.conf - a simple demonstration of XXX support.

- rb.conf - a simple demonstration of XXX support.

- reassemble.conf - this configuration demonstrates the tilesort SPU and the render SPU's ability to render back into the application's window (on X only; not Windows). The application node uses a tilesort SPU to talk to two crservers. Each crserver has a readback SPU. The readback SPUs render into the original application window, rather than separate windows.

  This configuration also demonstrates dynamic retiling. When the application window is resized, the tilesort SPU's tiling is changed.

- rbple.conf - a simple demonstration of zPix support with PLE, a Chromium inspired RLE compression method.

- readbacktest.conf - a simple demonstration of readback SPU support.

- retile.conf - a simple demonstration of dynamic tile layout support.

- saveframe.conf - a simple demonstration of saveframe SPU support.

- simplemural.conf - this configuration demonstrates a two-tile tilesort configuration. The application node has a tilesort SPU which sends commands to two crserver nodes, each with a render SPU.

- stereo[1234].conf - demontrations of various stereo rendering solutions. See the comments in each file for details.

- swapsync.conf - a simple demonstration of using the render SPU swapbuffer synchronization feature.

- threadtest.conf - demonstration of several multi-threaded rendering methods. See the file's comments for details.

- tiledump.conf - a simple demonstration of XXX support.

- warp_demo.conf - a simple demonstration of warped tile support in the tilesorter.

There are lots of other samples to look at in the same directory.