Opened 8 years ago

Last modified 8 years ago

#4914 new defect

jarabe windows are redrawn excessively

Reported by: quozl Owned by:
Priority: Normal Milestone: Unspecified
Component: Sugar Version: Git as of bugdate
Severity: Minor Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: New

Description (last modified by quozl)

Extra redraws of graphics windows cause performance to degrade. The following are some of the extra redraws in Sugar 0.107.0:

  1. when starting an activity, the pulsing icon is redrawn for the entire width of the screen, instead of only the area that has changed,
  2. in the neighbourhood, friends, and home views, palette popup or popdown over buddy icon, access point icon, or activity icons causes redraw of entire window, but only if the search entry is not in focus (perhaps caused by a focus indicator redraw of a child widget),
  3. in the neighbourhood, friends, and home view, when the search entry has focus the entire widget is redrawn on every cursor blink,
  4. switching to the home list view redraws it twice,
  5. journal details view redraws the entry name after drawing the entire window,
  6. journal Documents view draws several times when shown,
  7. switching from journal to home view draws entire window an extra time,
  8. switching from Documents view to Journal view redraws entire window twice,
  9. my settings, about me, nickname redraws after window draws,
  10. my settings, date & time, list of zones redraws after window draws,
  11. my settings, network, server and social help server redraw after window draws,
  12. my settings, modem configuration, all fields below the horizontal rule redraw,
  13. invoking the frame redraws the entire neighbourhood, friends, and home views, but not the journal view, but only if the search entry is not in focus,
  14. some frame device icons are redrawn even though the amount of change is insufficient to show a different icon; such as wireless access point signal strength, and battery state of charge.
  15. even with transition box removed, switching between neighbourhood, friends, and home views redraws the final view twice.

Reproducer: change the !__init!__ method in src/jarabe/desktop/homewindow.py by adding these lines to the end of the method:

        window = self.get_window()
        if window is not None:
            window.set_debug_updates(True)

Restart Sugar.

Reference: https://lazka.github.io/pgi-docs/Gdk-3.0/classes/Window.html#Gdk.Window.set_debug_updates

Change History (6)

comment:1 Changed 8 years ago by quozl

  • Description modified (diff)

comment:2 Changed 8 years ago by quozl

  • Description modified (diff)

comment:3 Changed 8 years ago by quozl

  • Description modified (diff)

comment:4 follow-up: Changed 8 years ago by godiard

Very interesting.
Some ideas, without looking too much at the code:

  • Maybe you can use set_can_focus(False) in the neighborhood, friends, and home views, to avoid them grab the focus. Not sure if that will affect keyboard interactions.
  • extensions/deviceicon/battery.py battery_properties_changed_cb do always the self.emit('updated') triggering the redraw, even if the values didn't changed.
  • deviceicon/network.py, should check previous states to try avoid change color and other icon properties if not needed.
  • Journal: I remember cases where the first time we switch to the journal, we see the window resizing to full screen. I don't know why and if is needed, and if the next switches do a resize too.
  • View switches: desktop/homewindow.py remove the view widget, add a transition box (to show the kid icon anumation), and add the new view widget. Not sure if that trigger unneeded resizes. Maybe we can use a Gtk.Notebook and just change pages? (And/Or remove the transition box step at all)

[1] https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-can-focus

comment:5 in reply to: ↑ 4 Changed 8 years ago by quozl

Replying to godiard:

  • Maybe you can use set_can_focus(False) in the neighborhood, friends, and home views, to avoid them grab the focus. Not sure if that will affect keyboard interactions.

Thanks, I've been experimenting with that, please have a look at
https://github.com/sugarlabs/sugar/pull/616

Keyboard interactions don't appear to work anyway, so we haven't lost much if we avoid focus leaving the search entry widget. It looks like it would be a lot of work, but of benefit for accessibility, if keyboard focus navigation could be fixed.

comment:6 Changed 8 years ago by quozl

Item 1 was in 0.107.1.

Item 2 is pending review, but is in OLPC packages.

Note: See TracTickets for help on using tickets.