Francois Sillion (Francois.Sillion++at++imag.fr)
Fri, 20 Nov 1998 17:38:48 +0100
Since there seems to be a lively discussion on Pbuffers, please let me ask my
last question again: I ran into some similar problems trying to find a correct
FB config for my Pbuffer: specifically I have to use a double-buffered buffer
because none of the available single-buffered ones is accepted by X. I don't
know if this double-buffering is the cause for my problem, but then I can't
get a correct rendering unless I specify the GLX_PRESERVED_CONTENTS attribute.
This is not an acceptable solution because it creates a huge performance
penalty in Performer.
Would you be so kind to also take a quick look at the question of
non-preserved contents? I am attaching my earlier post below. Also, please
keep the discussion on the list since there are other people interested.
Thanks a lot,
>
> From: Phil Keslin <philk++at++cthulhu.engr.sgi.com>
> Date: Thu, 10 Dec 1998 10:32:05 -0800
> Subject: Re: pBuffer
>
> Rob Jenkins wrote:
> >
> > Ruediger Westermann wrote:
> > >
> > > Hi Rob,
> > > Many thanks for your reply.
> > > The thing i don't understand is that i search the list
> > > until i find the configuration i want to have (8,8,8,8,>1).
> > > I only select the visual if the requirement is satisfied.
> > > However, sometimes there is only one entry (12,12,12,12,24)
> > > in the list, which can not be allocated.
> > >
> > > Any idea ?
> > >
> >
> > Hi
> >
> > I CC'd this back to the list in case anyone else was tuned in, I know a
> > few people have/are grappling with this kinds of issues.
> >
> > In my first response I thought you were doing 'bits >= 8' but actaully
> > you do 'bits == 8' so my words about getting RGBA12 first might not be
> > relevent.
> > The other stuff about considering you minimal config and fallback cases
> > is valid though.
> > The missing piece in this is probably the PixBuffer::configAttribList
> > that you use, could you post that and I'll take another swing :-)
>
> The answer to the question is very dependent upon the target graphics
> hardware and the current framebuffer configuration. Some machines won't
> have sufficient resources to allocate depth and color buffers for a
> pbuffer simultaneously. If you tell me what configs you are trying to
> support, I might be able to give you a better feel what you can and
> cannot do.
>
> - Phil
> --
> Phil Keslin <philk++at++engr.sgi.com>
-- +------------------+--------------------------------------------------------+ | Francois SILLION | iMAGIS-GRAVIR/IMAG/INRIA, BP 53, 38041 Grenoble Cedex 9| | ' | France. Tel: +33 4 76 51 43 54 - Fax: +33 4 76 63 55 80| +------------------+--------+-----------------------------------------------+ | Francois.Sillion++at++imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+-----------------------------------------------+X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Message-ID: <36559B18.CD5A466++at++imag.fr> Date: Fri, 20 Nov 1998 17:38:48 +0100 From: Francois Sillion <Francois.Sillion++at++imag.fr> Organization: iMAGIS - IMAG/INRIA X-Mailer: Mozilla 4.5 [en] (X11; I; IRIX 6.3 IP32) X-Accept-Language: en MIME-Version: 1.0 To: info-performer++at++sgi.com Subject: PBUFFER issue on iR : image is garbage... clobber problem? References: <199811201000.CAA18416++at++holodeck.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Dear Performers,
In my application I have two pipeWindows, one rendering to a window on screen and one rendering to an (offscreen) P-buffer. This works fine on an O2.
I have the following problem running it on an iR:
- If I create my P-buffer with the GLX_PRESERVED_CONTENTS_SGIX attribute, rendering in the main (on-screen) window is slowed down terribly, even if the offscreen pipewindow is doing nothing (i.e. has no channel attached to it). SGI support identified this as the source of the performance problem (thanks a lot to them!), but
- if I do not specify the GLX_PRESERVED_CONTENTS_SGIX attribute, performance is as expected, but the image I extract from my Pbuffer is garbage.
Looking at the Pbuffer doc, I found that when contents are not preserved, the Pbuffer can be trashed at any time, but with an (asynchronous) notification by means of a clobber event. The man page also suggests grabbing the X Server.
- I tried grabbing the X server: the draw callback on my offscreen channel looks then like: ============================= static void DrawOffScreenChannelCB ( pfChannel * pChannel , void * ) { pfEnable(PFEN_LIGHTING);
pChannel -> clear ();
XGrabServer( pfGetCurWSConnection() );
pfDraw(); GatherOffscreenData(); // this function simply calls glReadPixels to get the // image from the Pbuffer into memory
XUngrabServer( pfGetCurWSConnection() ); } ============================= but the contents of my image is still garbage...
- I also wanted to try reacting to CLOBBER events, but could not find any examples. the man page says I can use glXSelectEventSGIX to register for this type of event, but then what? I only know how to set an event handler for an Xt Widget using XtAddEventHandler.. but my pbuffer is not a widget! how do I specify how to react to a clobber event?
- One final note: on the iR my program allocates a DOUBLE-BUFFERED pbuffer, because the (single) FB config found for single buffer pbuffers is refused by glXCreateGLXPbufferSGIX (BadAlloc (insufficient resources for operation). Could this have to do with my problem? in case you wonder, I HAVE tried reading pixels from the front and the back buffers, I have garbage in both!
Could someone help me really understand how I can ensure I get a correct image of what I have drawn? example code would greatly help.
Thanks a lot!
This archive was generated by hypermail 2.0b2 on Fri Dec 11 1998 - 02:37:55 PST