We saw that the progress in hardware accelerated graphics was incredible - driven to a large extent by the gaming and the 3D world. But until recently getting to the hardware was a problem - there were a whole bunch of imcompatible API's out there. Each workstation manufacturer had their own proprietary API and the situation on PC's was worse.

Finally OpenGL achieved widespread support in both Unix and Windows environments. While 3D is the main emphasis for the graphics card people, we get a free ride in most cases for our 2D applications.

We're pleased with how well OpenGL is integrated into the Sun hardware and since UltraSparc seems to be our customer's platform of choice it's made our life simpler. We are just now evaluating how well HP's newer Visualize workstations deal with OpenGL and I believe the results there will be excellent.

Downsides to OpenGL? Well, first only Sun/HP workstations that are about a year old have the combination of fast CPU and OpenGL support. So I guess that leaves out anyone with older hardware. Also, if you have a fast workstation but installed the PGX graphics (no acceleration) you won't want to use Qckvu.

We'll also have to make sure that the user has the latest OpenGL libraries properly installed and we are also seeing that the particular graphics settings on the card make a difference. We've written a program now that will check for all the right libraries, right hardware and even measure the OpenGL performance during the install process.

Finally, we're not sure if this approach will be suitable for EDA compute farms - that's where the company has a cluster of really big fast machines in the basement and each user has a low cost workstation on his desk which is logged into the server farm. Some of our customers have told us this is how they plan to setup their design teams.

We tracked the problem to the fact that you remote logged into the window used for Qckvu. Here is what is happening (and what you can do about it.)

OpenGL renders directly to the display's frame buffer bypassing the X server (which serves as the underpinnings for CDE and OpenWindows.) This is made possible by Sun's Direct Graphics Access (DGA) mechanism for locking portions of the screen. So while the user interface lives on top of CDE or Openwin, the actual screen draws live underneath and don't incur any overhead of the X server.

Solaris security allows only the user who originally logged into the window system to use DGA to lock portions of the screen. Non-owners of the window system do not have access to DGA.

If you notice poor performance when running Qckvu locally, the cause is likely this Solaris security feature. For example, if you start the window system and another user at the workstation changes to the user's own environment using su, the application will not run via DGA even though the second user is running the application locally.

To make the change permanent, the sysadmin should edit the file /etc/logindevperm and change the default permissions of the devices to 0666 to allow world read/write access.