Performer came about in 1991 when a group from SGI's Open Inventor project, then known as IRIS Inventor, decided to focus on performance rather than ease of programmability. Whereas Inventor delivered easy-to-use objects and various UI elements to interact with them, Performer focused on a scene graph system that could be re-arranged on the fly for performance reasons, allowing the various passes of a rendering task to be performed in parallel in multiple threads. Performer allowed the scene to describe levels of detail with hysteresis bands and fade capabilities. Frame rate and statistics were monitored and a 'stress' factor was calculated. This could be used to further weight the level of detail in the scene eliminating detail to maintain a target frame rate. Other key features of Performer were the use of symmetric multi-processing capabilities, support multiple graphics pipes and the ability to utilize the scalable resources of high end systems. In this regard Performer was actually simple to use given the underlying complexity. Application culling and rendering could be running in different threads locked to different physical processors. In a multi-pipe (multiple graphics subsystems) configuration rendering to each graphics pipe would have a dedicated thread and similarly culling would also have a dedicated processor. Advanced features like database paging, texture paging and point light source management (for flight simulation) and intersection testing for collision detection would also have dedicated processors allowing asynchronous i/o and processing to occur without negatively impacting graphics performance. Most of this complexity was hidden beneath a simpler scene graph API with relatively high level configuration calls which could be made to set up the threads and inter-process communication.