home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!sun-barr!olivea!sgigate!odin!sgihub!zola!kahua.esd.sgi.com!paquin
- From: paquin@kahua.esd.sgi.com (Tom Paquin)
- Newsgroups: comp.sys.sgi
- Subject: Re: GLX slow rendering problem
- Keywords: GL, GLX, shaded rendering
- Message-ID: <paflvn4@zola.esd.sgi.com>
- Date: 1 Sep 92 18:31:26 GMT
- References: <14891@borg.cs.unc.edu>
- Sender: news@zola.esd.sgi.com (Net News)
- Distribution: usa
- Organization: Silicon Graphics Inc.
- Lines: 31
-
- soltys@phoenix.radonc.unc.edu (Mitchel Soltys) writes:
-
- |>
- |> for(i = 0; i < num_triangles;i++){
- |> bgnpolygon();
- |> n3f(fake_vector);
- |> v3f(fake_vector);
- |> n3f(fake_vector);
- |> v3f(fake_vector);
- |> n3f(fake_vector);
- |> v3f(fake_vector);
- |> endpolygon();
- |> }
- |>
- |> takes ~1.6 secs ... more than three times as slow.
-
-
- Hm. Well, the bgnpolygon, n3f, v3f and endpolygon code hasn't changed
- one whit. Your process is executing the same instructions with or
- without X. But the system may be getting involved, for reasons I
- don't understand. (And I should- I do know about the kernel/window
- system/graphics relationships.)
-
- I don't have an answer, but I can confirm that the GL code is
- identical. I hope someone can shed some light on this.
-
- --
-
- -Tom
- *****
- Opinions are mine, etc.
-