Difference between revisions of "Features/Optimize TreeViews"

m (sort in Category view)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
<noinclude>
 
<noinclude>
[[Category:Feature Page Incomplete]]
+
[[Category:FeatureLanded|Optimize TreeViews]]
[[Category:Feature|Optimize TreeViews]]
 
 
</noinclude>
 
</noinclude>
  
Line 14: Line 13:
  
 
== Current status ==
 
== Current status ==
* Targeted release: 0.102
+
* Targeted release: 0.104
* Last updated: Feb 24, 2014
+
* Last updated: Nov 17, 2014
* Percentage of completion: 60%
+
* Percentage of completion: 90%
  
 
== Detailed Description ==
 
== Detailed Description ==
Line 25: Line 24:
  
 
* Sugar CellRendererIcon has too much logic inside.  It should only handle how to render itself.
 
* Sugar CellRendererIcon has too much logic inside.  It should only handle how to render itself.
 +
In particular, a CellRenderer is not a Widget, then do not have event to know when the mouse interact,
 +
then needed attach to the events on the treeview [https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/graphics/icon.py#L826]
  
 
* Sugar CellRendererIcon is connected to many signals.  Just detaching them while scrolling provides a performance boost.
 
* Sugar CellRendererIcon is connected to many signals.  Just detaching them while scrolling provides a performance boost.
Line 30: Line 31:
 
* Sugar CellRendererIcon could benefit from caching values instead of calculating them on each render.
 
* Sugar CellRendererIcon could benefit from caching values instead of calculating them on each render.
  
We couldn't find what's wrong with the Journal. We guess there is a DBus blocking call, but we could't confirm that.
+
* There are a additional block in the Journal. That is not addressed by this feature, we guess there is a DBus blocking call,  
 +
but we could't confirm that.
 +
 
 +
=== Implementation ===
 +
 
 +
* ScrollingDetector: A new class ScrollingDetector allow simplify slow operations while the treeview is scrolling.
 +
To use it, just do:
 +
 
 +
scrolling_detector = ScrollingDetector(self._scrolled_window)
 +
scrolling_detector.connect_treeview(self._tree_view)
 +
 
 +
* CellRendererIcon changes:
 +
 
 +
The CellRendererIcon is not a widget, then, do not receive events when the mouse
 +
enter or leaves, and all the logic in the CellRendererInvoker is more complex than should be.
 +
Worst, we had 6 different CellRendererIcons in the Journal, then we simplified (and solved issues) implementing a
 +
TreeViewInvoker. The TreeView knows where is every cell then the code is much more simple.
 +
 
 +
The ObjectPalettes was created in the mouse enter callback, then if a user moved
 +
the mouse cursor over the activity icons, many palettes were created, and that palette creation is expensive [http://bugs.sugarlabs.org/ticket/4343].
 +
Moving the palette creation to the treeview, we can create the palette when the mouse was in a cell for a specified timeout and not before.  
  
 
=== GTK+ concepts ===
 
=== GTK+ concepts ===
Line 39: Line 60:
  
 
* GtkCellRenderer — An object for rendering a single cell https://developer.gnome.org/gtk3/stable/GtkCellRenderer
 
* GtkCellRenderer — An object for rendering a single cell https://developer.gnome.org/gtk3/stable/GtkCellRenderer
 
  
 
== Benefit to Sugar ==
 
== Benefit to Sugar ==
Line 51: Line 71:
  
 
== How To Test ==
 
== How To Test ==
We did a test program that has a list (treeview) with many rows.  Each row has a cellrenderer icon.  The program automatically starts scrolling until the end of the list is reached.  Then we can get profiling information using Python cProfile http://docs.python.org/2/library/profile.html .  We ran the test like this inside a Sugar shell:
 
  
     python -m cProfile test_treeview.py > profile.txt
+
To test the changes in the journal we used a python program to start the journal window from a terminal.
 +
You can download it here [http://dev.laptop.org/~gonzalo/start_journal.py]
 +
 
 +
To use it do:
 +
 
 +
     python -m cProfile start_journal.py > profile.txt
 +
 
 +
After run it in a Sugar terminal, the view jump to the Home, but in the frame you can see two journal icons.
 +
The second is the profiled version. In the toolbar have a Stop button.
 +
After stop, you can check the profile.txt file.
  
 
== User Experience ==
 
== User Experience ==
Line 72: Line 100:
 
== Comments and Discussion ==
 
== Comments and Discussion ==
 
Your comments are very welcome. Please discuss through the mailing list.
 
Your comments are very welcome. Please discuss through the mailing list.
 +
 +
The initial announcement in the mailing list is here [http://lists.sugarlabs.org/archive/sugar-devel/2014-February/047236.html]

Latest revision as of 10:51, 21 July 2015


Summary

Gonzalo Odiard and Manuel Quiñones did a hackaton to find out why the lists that contain icons are so slow. The affected views in Sugar are the Journal list and the activities list. This feature is about improving the TreeView performance.

Owner

Current status

  • Targeted release: 0.104
  • Last updated: Nov 17, 2014
  • Percentage of completion: 90%

Detailed Description

Findings

  • Sugar CellRendererIcon has too much logic inside. It should only handle how to render itself.

In particular, a CellRenderer is not a Widget, then do not have event to know when the mouse interact, then needed attach to the events on the treeview [1]

  • Sugar CellRendererIcon is connected to many signals. Just detaching them while scrolling provides a performance boost.
  • Sugar CellRendererIcon could benefit from caching values instead of calculating them on each render.
  • There are a additional block in the Journal. That is not addressed by this feature, we guess there is a DBus blocking call,

but we could't confirm that.

Implementation

  • ScrollingDetector: A new class ScrollingDetector allow simplify slow operations while the treeview is scrolling.

To use it, just do:

scrolling_detector = ScrollingDetector(self._scrolled_window)
scrolling_detector.connect_treeview(self._tree_view)
  • CellRendererIcon changes:

The CellRendererIcon is not a widget, then, do not receive events when the mouse enter or leaves, and all the logic in the CellRendererInvoker is more complex than should be. Worst, we had 6 different CellRendererIcons in the Journal, then we simplified (and solved issues) implementing a TreeViewInvoker. The TreeView knows where is every cell then the code is much more simple.

The ObjectPalettes was created in the mouse enter callback, then if a user moved the mouse cursor over the activity icons, many palettes were created, and that palette creation is expensive [2]. Moving the palette creation to the treeview, we can create the palette when the mouse was in a cell for a specified timeout and not before.

GTK+ concepts

Benefit to Sugar

Performance!

Scope

Affects Shell and Toolkit.

UI Design

We should not regress treeviews. Pay special attention to Journal list and activities list.

How To Test

To test the changes in the journal we used a python program to start the journal window from a terminal. You can download it here [3]

To use it do:

   python -m cProfile start_journal.py > profile.txt

After run it in a Sugar terminal, the view jump to the Home, but in the frame you can see two journal icons. The second is the profiled version. In the toolbar have a Stop button. After stop, you can check the profile.txt file.

User Experience

Users should notice a performance boost.

Dependencies

No deps.

Contingency Plan

These optimizations can come in small steps, so there is no need for a contingency plan.

Documentation

To be written.

Release Notes

To be written.

Comments and Discussion

Your comments are very welcome. Please discuss through the mailing list.

The initial announcement in the mailing list is here [4]