Performance Notes

The following sections contain perfofrmance notes for the Creator Accelerator on various applications.

Direct Xlib

Direct Xlib is not supported on the Creator accelerator. The X shared memory transport feature (new in Solaris 2.5) should be used instead. To enable shared memory transport, set the following environment variables in the client environment:

setenv DISPLAY :0

setenv XSUNTRANSPORT shmem

setenv XSUNSMESIZE 512

The last line specifies a client request buffer size of 512 kilobytes. Different request buffer sizes can be specified. However, 512 is a good compromise between the transport speed and the system memory resources consumed.

Applications that rely on XPutImage and Direct Xlib for fast pixel transfer into the frame buffer should instead use the MITSHM extension function XShmPutImage on the Creator accelerator. This function provides the fastest transfer of pixels into the frame buffer when the client is on the same machine as the X server.

If you are using XShmPutImage to a 24-bit visual, you may need to increase the amount of allocated shared memory beyond the default amount. See "The X11perf Benchmark"" for details.

The X11perf Benchmark

If you are running the x11perf benchmark when the default server visual is 24-bit TrueColor, the -shmput<nn> tests will fail. This is because this test requires more shared memory than that provided by the default shmsys configuration. The X11R5 version of x11perf version will core dump, while the X11R6 version will report an error and make no measurement.

To run this test, you will need to increase the amount of shared memory.

1. To increase the amount of shared memory, add the following line to /etc/system:

   set shmsys:shminfo_shmmax=8192000

No Creator Pixel Copy Hardware

The Creator accelerator does not have hardware for copying pixels within the frame buffer. Pixels are copied by reading the pixels into CPU registers and then writing them back to the frame buffer. Thus, pixel copies within the frame buffer are CPU-intensive. When the system is under heavy load, the performance of window dragging operations may suffer. For example, the ShowMe Whiteboard "Snap Region" image drag operation may slow down while an active SunVideo stream is being rendered. This effect does not occur on a TurboGX accelerator, which has pixel copy hardware.

Background None Window Transient Color Effects

Dragging the imagetool image palette window with mouse shift-left over the main imagetool window can leave areas of the main window temporarily cyan-colored. These areas are quickly repaired, but persist long enough to be noticed. The effect is particularly pronounced when the window being dragged is partially inside and partially outside the imagetool main window. These effects occur because the imagetool main window is an Xview WIN_TRANSPARENT window. This means the background of the corresponding X window is set to None. For this type of window, the server relies on the application to repair damaged areas after an occluding window is moved. This method of damage repair is inherently slow because the client must process damage events and send rendering requests.

The imagetool image palette window is an 8-bit window. The pixel data resides in the Creator accelerator 8-bit red channel. The background pixel value of this 8-bit window is a small number, typically 0x02. The data in the red channel doesn't damage data in the green and blue channels. The background of the main window was white (0xffffff) but when the 8-bit window occludes, the pixel values are 0xffff02.

When the 8-bit window occludes the area, it is viewed as an 8-bit window. But when the 8-bit window is moved, the server immediately changes the window ID values in this region, indicating that the region is now to be viewed as a 24-bit window. This happens before the background is repaired. So, for a moment, the old pixel values in this region (0xffff02) are viewed as a 24-bit pixel. This pixel value is viewed as pure blue + pure green, which forms cyan.

This effect can also be seen on the SX frame buffer, although the SX frame buffer stores its 8-bit windows in the blue channel, so the transient color is green + red, which appears as yellow.

This effect is not as noticeable on the SX frame buffer, because it is more difficult to detect a contrast difference between yellow and white. On the Creator accelerator however, the difference between cyan and white is more pronounced. The effect also takes longer to go away when the dragged window is partially outside the imagetool window. This occurs because the Creator hardware has more rendering state to maintain than the SX frame buffer; dragging outside the imagetool window causes the window manager to continuously update the imagetool window header. This causes text rendering operations to be interleaved with copy operations. And since both operations use different rendering state, the state must be continually loaded and reloaded into the Creator hardware context. Thus, the repair of the transient color regions in on Creator in this situation is slower than the SX.

This example has dealt specifically with imagetool, but this will happen with any X window whose background is set to None. A bug for this has been filed for imagetool (Bug id 1215303).

To summarize, transient color effects like the one described above will occur on any window that has Background set to None. Applications that use this type of window should use some another background mode to avoid these effects. The X server can then repair the damage soon after it occurs.