Footnote is extremely slow

[Andrea Basso]

Footnote now takes about 10 seconds to start on a Core 2 Duo. The window appears immediately, but it takes a lot to show the "inside".
Even adding a new note to a notebook with ~30 notes takes about the same time.
Switching notebook takes 4/5 secs.
It can't be used with these delays.

[Tom Beckmann (tombeckmann)]

"Now" meaning that wasn't like this some revisions before? If so do you remember the revision which changed that?

[Andrea Basso (voluntatefaber)]

With revision 50 it was fast and efficient, then I haven't tested all revisions till 60, as soon as I can I'm going to test all revisions between 51 and 59 and report here when this started.

I haven't checked yet because I thought it was a common problem, is it only me who's experiencing this problem?

[Tom Beckmann (tombeckmann)]

For me it's no problem, everything runs as fast as possible.

[Andrea Basso (voluntatefaber)]

Ok, after some tests I got:

At revision 51 it was still fast as it's always been.
At revision 52 startup remained fast, but switching notebook become very slow.
At revision 53 even startup become very slow.

[Tom Beckmann (tombeckmann)]

Which Desktopmanager do you use? Do you have hardware acceleration?

[Andrea Basso (voluntatefaber)]

I use unity 3D under Ubuntu, so yes, I have hardware acceleration.

[Andrea Basso (voluntatefaber)]

Forgot to say, Ubuntu 11.10

[Jaap Broekhuizen (jaapz-b)]

I have a i5 quad core using SandyBridge graphics, and i have indeed the same problem when adding 20+ notes. I guess it is because Gtk just doesnt like it when you show() and hide() that number of VBoxes every time you switch. I'm assigning myself to this as i am the one who caused it, i'm going to think of a nice solution!

[Andrea Basso (voluntatefaber)]

After some test I found out these are the two parts that takes a lot at start-up. Both are located in NoteView.vala

First part:

foreach (Gtk.Widget w in get_children ()){
    print ("\nA");
    if (w.visible) //check if we need to show/hide it
         w.hide();
}

Second part:

if (app.selected.category != null)
 foreach (Note n in app.selected.category.notes) {
  if (filter == "" ||
      filter.down () in n.title.down () ||
      filter.down () in n.content.down () ||
      n.tag_area.has_tag(filter)) {
   if (!n.visible)
    n.show_all ();
    showed++;
  }else{
   if (n.visible)
    n.hide ();
  }
 }

[Jaap Broekhuizen (jaapz-b)]

Yes, like i said, the hiding and showing of widgets is very slow. You can expect a fix somewhere at the end of this week!

[Andrea Basso (voluntatefaber)]

Thanks, I'm glad to hear that, right now I'm stuck to rev 49.

[Jaap Broekhuizen (jaapz-b)]

I pushed a fix that made rendering notes significantly faster on my machine, could you please test it (rev 63)? Rendering is still not very snappy, and i guess that is because we are using Granite.Drawing.BufferSurface, which is, quoting the documentation, "designed for usage with large, rarely updated draw operations", and notes are neither large nor rarely updated...

[Tom Beckmann (tombeckmann)]

I removed Granite.BufferSurface in rev65, for me it's faster.

[Andrea Basso (voluntatefaber)]

To me now it's fast enough to be usable and even better than before.

[Jaap Broekhuizen (jaapz-b)]

Faster here too, though the gradient around the note is not very nice, but i guess that is not relevant here. Marking as fixed!