CLIM mail archive
[Prev][Next][Index][Thread]
Re: Caching CLIM generated menus?
From: clarisse@iexist.att.com
Date: Wed, 1 Jun 94 17:51:10 CDT
To: swm@harlequin.com
Subject: Re: Caching CLIM generated menus?
Cc: clim@BBN.COM, bugs@franz.com
>
> The Sparc 10 I have generates such menus with 15 to 20 items in about
> 1 second. How big are your menus?
>
Our longest menus are 15 items long. After mouse-right selection, they
take 2-3 seconds to appear the first time. If all I do is a lot of
right selection, the lapse time seems to go down to 1 second. Even
1 second for these feels slow in this case.
In some cases the menu gets redisplayed twice (redrawn) adding another
1/2 second before the user will feel like selecting something that's not
a moving target, and this happens once out of every 3-5 selections.
Nothing ever changes in the menu except for the name of the presentation
object. I could live with a mode where when a command is added the
menu needs be recomputed.
Yes, our users find this kind of thing extremely annoying.
>
> The presentation menus can't really be saved, because there are many
> things that dynamically change that can affect the contents of the
> menu.
Things may be dynamic, but are they too dynamic to have nothing worth
caching? Even doing an equal hash on the menu items might help.
> You could always define a new mouse-right translator for your own
> type(s) that simply exposes a previously-generated menu. Then you
> have to worry yourself about fixing up the menu if it becomes "stale".
> (The staleness problem is exactly why CLIM doesn't do this.)
>
I'd like to try this:
could you elaborate on this briefly, how would I grab the first
menu, I can figure out how to reuse it after that I think. But I have no clue
how the CLIM menu gets generated at first. Or are you saying I should walk
down the applicable commands myself and generate something appropriate
for my application? I'll start with that.
References:
Main Index |
Thread Index