Mini-Conference Proposal: sugar performance

[Tomeu Vizoso]

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
>  activities.
>
>  Regards,
>  Gary
>
>  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:

http://lists.laptop.org/pipermail/devel/2008-March/012094.html

Tomeu