Mini-Conference Proposal: sugar performance
tomeu at tomeuvizoso.net
Mon Mar 24 14:04:10 EDT 2008
On Sun, Mar 23, 2008 at 9:01 PM, Gary C Martin <gary at garycmartin.com> wrote:
> On 23 Mar 2008, at 18:32, Tomeu Vizoso wrote:
> > The idea is that, instead of waiting 5 seconds for the full UI to
> > appear, the activity window would appear after, say, 3 seconds, half a
> > second later the document will get loaded, and half a second later the
> > user will be able to share the activity or invite somebody.
> > Can your activities do something about this?
> I have just one activity at the moment, Moon, the difficulty I'd face
> is that I really don't want multiple redraws at start-up for what
> you're calling the document area, it's quite cpu expensive in my case
> (at least a second or so per refresh). And I have a planned activity
> where it may be even worse (a lon/lat tag sharable 3D Earth view).
> Currently there is no way an activity can know (in its __init__) if
> read_file() is going to be called
handle.object_id is not enough? If no value is in there, the activity
was started anew. If there's a value, that's the object id of the
journal entry that the activity should be resuming.
> so with your proposed changes, yes
> I can (and do) set-up the default tool bar, a black screen and my text
> panel early, but I'd then need to have my __init__ set-up a timer to
> arbitrarily ~0.5 or more sec, just incase a read_file() call arrives.
> So every fresh launch will twiddle it's fingers for an extra
> unnecessary ~0.5 sec, and if after a Journal launch and the ~0.5 sec
> was not long enough, the user will get a nasty double redraw of the
> main cpu expensive widget refresh, slowing things down even more (and
> looking bad as well).
> Letting the activity know data is, or isn't, expected from the Journal
> is the missing feature here. Always having a read_file() xor a
> clean_start() call would resolve this. Other options could be to just
> always call read_file() data or no data and let the activity deal with
> perhaps a file_name = None, but that will likely break some existing
> P.S. clean_start() is just a stand-in name, sure you'd have a better
> name for it, maybe no_file()? On OS X under Cocoa we have the usual
> init method to get the base things going, and then later an
> awakeFromNib method is called so that an application knows its
> resource files have been dealt with by the runtime – that's when we
> can start parsing preference settings etc and tweaking the UI to
> match. There's even then a final applicationDidFinishLaunching method
> you override to kick things off once the set-up is all over.
This Mikus' post explains much better what I was trying to:
More information about the Devel