Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!goldenapple.srv.cs.cmu.edu!das-news2.harvard.edu!cam-news-feed3.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!ix.netcom.com!kthompso
From: kthompso@netcom.com (Kevin Thompson)
Subject: Re: [VW] Notebook Widget performance optimization
Message-ID: <kthompsoE7Ct0y.JI7@netcom.com>
Organization: Netcom
References: <332DC63C.5AD@fedex.com>
Date: Thu, 20 Mar 1997 18:07:46 GMT
Lines: 79
Sender: kthompso@netcom6.netcom.com

In article <332DC63C.5AD@fedex.com>, Rick Holland  <rghollan@fedex.com> wrote:
>Has anyone out there done any work at enhancing the performance of the
>VW Notebook widget?
>
>Would like to run several ApplicationModel instances whose components
>are displayed within a Notebook in a single window no more CPU intensive
>than several ApplicationModels whose components are displayed in several
>separate overlaping windows.
>
>It looks like the biggest bottle-neck is the fact that each time a tab
>is selected the SubCanvas within the Notebook releases all current
>components and then rebuilds all components for the next set of
>components (even if that tab has been selected 1000 times before). I was
>thinking of creating a Notebook widget that maintained a collection of
>subcanvases, one for each tab/app-model (instead of reusing a single
>SubCanvas), and simply made them invisible/visible as notebook tabs were
>changed. I have created overlapping SubCanvases before within a window
>and made one visible and the other invisible based on state so I assume
>a Notebook could be implemented this way.

Caching within the widget itself is doable, but not by any stretch easy to
get exactly right.  I haven't written it in the notebook because we don't use
it (ugly widget), but we've done it in house for the general subcanvas case.
Your general approach as outlined above is about what we do; as an aside, you
should/could contact ObjectSoft, which has its own NotebookComposite subclass
that does what you are suggesting for the notebook.

Briefly, you want to cache an association between <something> and the
UIBuilder of that page.  What <something> is depends on how you use the
notebook; I would argue it should be the class->spec association because this
is the most general; I've seen it done via position (e.g. keep associations
3->aUIBuilder, 1->aUIBuilder, etc).

The question then is what to do when you get a request to display a new page.
You have to be careful; the obvious thing to do is to just send isVisible: to
the top level spec wrappers to make them visible and invisible.  This is not
general however if the contained components use visibility in any interesting
way; when you redisplay a cached app by saying isVisible: true then you'll
make *everything* visible, including some things that perhaps should not be.
Our solution has been to extend spec wrapper with a message to make something
invisible that only forwards isVisible: to the WidgetState, but does not
downcast the #visibility message.

Hope this helps.

Kevin































-- 
kthompso@netcom.com        
