Re: Overhead for rendering multiple windows

New Message Reply Date view Thread view Subject view Author view

Steve Baker (sbaker++at++link.com)
Wed, 29 Jul 1998 08:40:51 -0500 (CDT)


On Wed, 29 Jul 1998, Angus Dorbie wrote:

> Colin Bridgewater wrote:
> >
> > Hi Folks
> >
> > Regarding the overhead involved in rendering multiple windows from one
> > graphics pipe, the Performer Progammers' Guide states:
> >
> > > The use of multiple windows on a single graphics pipe can add
> > > overhead. The sharing of the graphics context between windows
> > > consumes almost all of this overhead.
> >
> > Would anyone care to be more specific as to what "almost" means ?
>
> Well how much does a glViewport, glFrustum, a modelview loadmatrix,
> a couple of matrix mode changes a glScissor and potentially another
> glClear (quite reasonably ignoring the time taken to actually
> perform the clear) cost?
>
> Not very much.

An important caveat is that you either need to render to those
two windows from within a single process - or perhaps try to
interlock the processes writing to different windows so that
they don't all try to draw at the same time.

If you have two processes writing to the same pipe AT THE SAME TIME,
then graphics context switching in the pipe can really kill your
performance on some (if not all) SGI platforms. When we tested this
(admittedly on an RE2 using IrisGL/Performer 1.2), we were seeing
a 45% slowdown due to these kinds of effects.

Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker++at++link.com http://www.hti.com
Home: SJBaker1++at++airmail.net http://web2.airmail.net/sjbaker1

=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:45 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.