Dynamic texture

New Message Reply Date view Thread view Subject view Author view

ipandzic++at++cui.unige.ch
Thu, 15 Jun 1995 18:35:51 +0200


Hello!

I'm trying to use the images produced by a non-performer application as
a dynamic texture in my Performer application. The image is a standard
RGBA format as convenient for texture mapping. It is being updated at
15 fr/sec by the source application. The image is in the shared memory
segment, and the Performer application is attached to the same
shared memory, thus getting the updated image all the time.

The problem is that I get an enormous performance penalty - on the
Onyx I go down to about 8 fr/sec from original 15 when I use this
method. I wonder if I can improve something.

Here are more details about the Performer application:

- the shared memory segment containing the images is "standard" shared
  memory allocated using shmget, not the Performer shared memory. The
  problem is that I can't use the image thus allocated as texture - if
  I try to give it to pfTexImage I get a segmentation fault. I solved
  this by copying the shared memory segment into Performer-allocated
  memory in each frame. Actually, this doesn't decrease the performance
  because the image is very small, but it is not a very nice way to do it.

- in order to update the texture in each frame, I have to call pfTexImage
  in each frame (if the texture-mapped object is not culled). Now, this
  gives the big performance penalty. I have tryed to use PFTEX_FAST_DEFINE
  but on the Onyx RE it gives a segmentation fault, and on the other
  machines it doesn't improve performance - I still have to call
  pfTexImage in each frame. The image is 64x64 pixels.

Well, this is the way I am doing it now, I wonder if somebody can suggest
a better (FASTER) way...

Regards,
Igor

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Igor Pandzic ipandzic++at++cui.unige.ch
MIRALab
University of Geneva tel. +41/22/705 76 56
24, rue General-Dufour 705 77 63
CH-1211 GENEVE 4
SWITZERLAND fax +41/22/705 77 80
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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:51:35 PDT

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