[info-performer] Re: Memory leak in Performer 3.1 for Windows

Date view Thread view Subject view Author view

From: Jaroslav Sinecky (jsin++at++host.sk)
Date: 04/21/2004 05:57:18

Hi Peter,
It sounds to me like similar problem I had integrating performer in MFC
application. This had a solution setting window class to "pfChildWNDCLASS"
for the graphic window (see bellow, read bottom-up). You can give it a try.
Jaroslav

-----Original Message-----
From: owner-info-performer++at++performer.engr.sgi.com
[mailto:owner-info-performer++at++performer.engr.sgi.com]On Behalf Of Peter
Krueger
Sent: Wednesday, April 21, 2004 9:34 AM
To: info-performer++at++sgi.com
Subject: [info-performer] Memory leak in Performer 3.1 for Windows

Dear Performer developers!
I've further investigated my problems of integrating a pfPipeWindow in my
graphical user interface. After I set the pfPipeWindow to
PFPWIN_TYPE_UNMANAGED the warnings from pfWindow::select disappeared, but
my application still crashes after some time. I noticed that there is a
memory leak of 1 KB per frame. This problem occurs with Performer 3.1 as
well as with Performer 3.1.1EA.
I've removed all unneeded parts from my test application and my final
runtime loop consists only of:

for (;;) {
  pfSync();
  pfFrame();
}

So I'm pretty sure that this is a Performer related memory leak.
This problem sounds exactly like the problem reported by Tiziano Diamanti
(Memory leak in 3.0/Windows too, Date: 02/12/2003 02:46:22).

Would you please make a statement whether there is still a bug in
Performer related to pfPipeWindow::setGLCxt()!

I've searched again my Performer installation, this function is not used
in any of the provided examples. If I'm doing something wrong and there is
no bug in Performer, could you please give me a small example code
listing how to use it properly?

Regards,
                     Peter 

--
====================================================================
Peter Kruger

applied software solutions (appss) GmbH
Sandtorstr. 23
D-39106 Magdeburg
Germany

Phone:  +49-(0)391-54486-19388
Fax:    +49-(0)391-54486-19222
email:  krueger++at++appss.de
URL:    http://www.appss.de/

Managing Director: Uwe Hess, Dietmar Schafer
Register: HRB12386, AG Magdeburg

"Virtual business becomes reality!"

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
====================================================================

-----Original Message-----
From: owner-info-performer++at++performer.engr.sgi.com
[mailto:owner-info-performer++at++performer.engr.sgi.com]On Behalf Of Jaroslav
Sinecky
Sent: Thursday, December 04, 2003 11:42 AM
To: Info-Performer
Subject: RE: [info-performer] Performer and MFC

Oh yes! it works. I set the Window Class for my CView derived view (not
directly CFrameWnd) in PreCreateWindow like this:

BOOL CMFCPerformerView::PreCreateWindow(CREATESTRUCT& cs)
{
	cs.lpszClass = "pfChildWNDCLASS";
	return CView::PreCreateWindow(cs);
}

The only detail is that pfChildWNDCLASS probably doesn't have a hCursor
assigned so the cursor is taking different shapes depending from which part
of screen it's coming. But it shouldn't be problem to fix by setting the
cursor on some "mouse enter" event.

Anyway performer is happy now and so am I. Thanks!

Jaroslav

ps. Appologize to Goncalo

> -----Original Message-----
> From: Alexandre Naaman [mailto:naaman++at++laplace.engr.sgi.com]
> Sent: Wednesday, December 03, 2003 5:56 PM
> To: Jaroslav Sinecky
> Cc: Info-Performer
> Subject: Re: [info-performer] Performer and MFC
>
>
> Hi Jaroslav,
>
>  Indeed there is a problem with pfWindow::swapBuffers(). The issue is that
> we call GetDC() every frame and it seems as though depending on how you've
> created your window with MFC, this will either cause a new DC to get
> created every frame, or not. Obviously, if it does this at every frame
> then you will leak memory like mad.
>
>  The problem is that if a window isn't created with the CS_OWNDC flag then
> Performer isn't happy. It's been a while since I've looked at this stuff
> and you're right, we're in the crunch for 3.1 right now but hopefully this
> will be of some help. Just for future reference, the bug # associated with
> this problem is 892106.
>
>  The key to fixing this problem is to call Create() as follows in your
> CFrameWnd constructor. Supposing you have a class called COPenGLWindow
> which derives from CFrameWnd then in the constructor you could do:
>
> COpenGLWindow::COpenGLWindow()
> {
>   Create("pfChildWNDCLASS",
>          _T("Simple MFC OpenGL Performer Application"));
> }
>
>  Note that the "pfChildWNDCLASS" part of this function call is quite
> important.
>
>  Hopefully this is enough to get you going. Really we should ship this as
> a piece of sample code .. maybe I can slap it into 3.1 on time for the
> release....
>
>  One final note of interest, a CStatic window doesn't get created with a
> CS_OWNDC flag and hence isn't well suited for use with Performer. There's
> probably some work we can do here to make things better but I haven't gone
> down that path, yet.
>
>  Please let me know if this helps,
>
> Alex.
>
> > Hello!
> >
> > We are considering migrating the graphical kernel of our MFC based
> > application from Optimizer to Performer (thanks new
> optimizer-like features
> > in pf3.1!). I found a reference to a simple example of
> MFCPerformer program
> > in performer-list archive (submitted by Jan P. Springer) and started off
> > with this sample. Also someone reported on the mailist that performer
> > applications based on MFC eat memory. Really the memory reported by task
> > manager is increasing slowly as the program is running but
> worse even the
> > performance falls down very rapidly. After couple minutes it gets
> > practically stuck.
> > I continued testing and to get more control over what's
> happening tryied MFC
> > application based on libpr only. This was behaving the same. Later I
> > realised "the bad thing" was happening in
> pfWindow::swapBuffers(). Indeed
> > when I changed this for simple ::SwapBuffers(HDC) the application got
> > finally stable. So what's happing in pfWindow::swapBuffers besides just
> > swapping buffers?
> > Then I tryied the libpf based application again but setting the type of
> > pfPipeWindow with PFPWIN_TYPE_UNMANAGED. According to man pages
> This should
> > turn off the position/size managment (the position really gets
> messed up)
> > and also automatic buffer swapping but it continued displaying
> frames (hence
> > swapping). So how does this flag works?
> >
> > The complete project files for both pf and pr version (for VC7)
> can be found
> > here:
> > http://home.tiscali.cz/pusher/mfcperformerpr.zip
> > http://home.tiscali.cz/pusher/mfcperformerpf.zip
> >
> > Most interesting things are happening in CMFCPerformer::InitApplication,
> > CMFCPerformerView::OnCreate and CMFCPerformerView::Frame.
> >
> > I can imagine performer team guys are having lot to do
> preparing 3.1 release
> > but I would be really glad if someone could have look at it.
> >
> > Or has someone else more success writting mfc-performer programs?
> >
> > Jaroslav
> >
> > *******************************************
> >
> > Jaroslav Sinecky
> > Topmes v.o.s. Prague
> > http://www.topmes.cz
> >
> > -----------------------------------------------------------------------
> >    List Archives, Info, FAQ:  http://www.sgi.com/software/performer/
> >    Open Development Project:  http://oss.sgi.com/projects/performer/
> >                 Submissions:  info-performer++at++sgi.com
> >             Admin. requests:  info-performer-request++at++sgi.com
> > -----------------------------------------------------------------------
> >               I/ITSEC 2003 Friends of Performer Meeting:
> >  Wednesday December 03, 6:30-8:30pm, Peabody Hotel, Florida I Ballroom
> > -----------------------------------------------------------------------
> >
>
> A+,
>
> Alexandre.
>
> --
> Alexandre Naaman - naaman++at++sgi.com

-----------------------------------------------------------------------
   List Archives, Info, FAQ:  http://www.sgi.com/software/performer/
   Open Development Project:  http://oss.sgi.com/projects/performer/
                Submissions:  info-performer++at++sgi.com
            Admin. requests:  info-performer-request++at++sgi.com
-----------------------------------------------------------------------
              I/ITSEC 2003 Friends of Performer Meeting:
 Wednesday December 03, 6:30-8:30pm, Peabody Hotel, Florida I Ballroom
-----------------------------------------------------------------------

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Apr 21 2004 - 06:17:57 PDT