If I drag a closed outliner around over an empty portion of the world, I am quite pleased with the redraw speed. But when I start dragging open outliners around over other open outliners, things really slow down.
An open outliner has 15 ba-zillion morphs in it. When you carry one open outliner over another that's 30 ba-zillion redraws coming down the wire.
It's not really bad locally, as other Ultra users have testified. I would take a wild stab and guess that your bottleneck is the speed of your X-server.
If we ever do another release, you would find an optional "simple outliners" mode. This is good for introductory programming -- regular outliners have become awfully decorated. (A "simple outliner" has somewhat fewer morphs.)
Sorry can't help much! Best of luck,
--Randy
Err -- not knowing much about how the outliner is implemented, this doesn't seem like a hard problem. When you start a drag, you cache the 'image' that is being drawn. Assuming that you have backing-store for the window you are dragging over, this is a very efficient operation.
Maybe this won't work for outliners, but it should unless they draw differently based on their position.
-tim
Begin forwarded message:
Date: Wed, 27 Nov 1996 23:59:08 -0800 From: randall.smith@Eng.Sun.COM (Randy Smith) To: self-interest@self.smli.com, cam@elliott.net Subject: Re: Zippier outliner development environment?
If I drag a closed outliner around over an empty portion of the world, I am quite pleased with the redraw speed. But when I start dragging open outliners around over other open outliners, things really slow down.
An open outliner has 15 ba-zillion morphs in it. When you carry one open outliner over another that's 30 ba-zillion redraws coming down the wire.
It's not really bad locally, as other Ultra users have testified. I would take a wild stab and guess that your bottleneck is the speed of your X-server.
If we ever do another release, you would find an optional "simple outliners" mode. This is good for introductory programming -- regular outliners have become awfully decorated. (A "simple outliner" has somewhat fewer morphs.)
Sorry can't help much! Best of luck,
--Randy
Err -- not knowing much about how the outliner is implemented, this doesn't seem like a hard problem. When you start a drag, you cache the 'image' that is being drawn. Assuming that you have backing-store for the window you are dragging over, this is a very efficient operation.
In general any morph is allowed to change its representation in any frame, for animation. For outliners, the values of the slots are updated even though the outliner is being dragged. Caching would defeat this.
-Mario
How common is this, though? At a minimum, you could cache a static drag image and a list of rectangles in that image that might change from frame to frame. This would presume that there is some way to tell if the morph wants to change on each frame. The implementation for this is quite a bit more complicated than a static drag image, but if it is very rare to have a morph that wants to display differently on each frame, the savings could be gained by only doing the caching if none of the morphs did this.
-tim
Begin forwarded message:
Date: Fri, 29 Nov 1996 00:02:31 -0800 From: mario.wolczko@Eng.Sun.COM (Mario Wolczko) To: tjw@omnigroup.com Cc: randall.smith@Eng.Sun.COM, self-interest@self.smli.com, cam@elliott.net Subject: Re: Zippier outliner development environment?
Err -- not knowing much about how the outliner is implemented, this doesn't seem like a hard problem. When you start a drag, you cache the 'image' that is being drawn. Assuming that you have backing-store for the window you are dragging over, this is a very efficient operation.
In general any morph is allowed to change its representation in any frame, for animation. For outliners, the values of the slots are updated even though the outliner is being dragged. Caching would defeat this.
-Mario
self-interest@lists.selflanguage.org
-
mario.wolczko＠Eng.Sun.COM -
randall.smith＠Eng.Sun.COM -
tjw＠omnigroup.com