From: Alexandre Naaman (naaman++at++laplace.engr.sgi.com)
Date: 12/03/2003 08:55:46
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
This archive was generated by hypermail 2b29 : Wed Dec 03 2003 - 08:56:05 PST