1. 07 Aug, 2017 1 commit
  2. 05 Aug, 2017 1 commit
    • Jonathan Wilkes's avatar
      throttle gui_canvas_get_scroll instead of debouncing · 869def26
      Jonathan Wilkes authored
      while debouncing this call can save re-layouts of the DOM, with indeterminate
      streams of redraws coming from Pd it can result in no re-layouts at all. In
      the case where a user opens a subpatch that has a redraw triggered by a
      [metro 200] object, there may not even be an initial layout. This can result
      in the patchsvg never getting its viewBox set and appearing not to display
      at all.
      One workaround could be to do an initial call immediately after mapping the
      window, but there are still cases (like resizing a window or adding objects)
      that could result in putting off a needed re-layout for too long.
      So instead of debouncing, we throttle. This means there will only be a
      single call every 250ms (or whatever value we want), but that call is
      _guaranteed_ to happen at the end of the chosen duration. So for a stream
      of redraws coming from a [metro 200] we'll get a re-layout every 250ms. That's
      more expensive than putting them off indefinitely, but obviously more
      responsive and usable.
      Ideally we would send a do_getscroll _first_ and then wait 250ms. That would
      result in a more responsive UX-- as it is the 250ms makes the initial window
      rendering appear sluggish. Unfortunately there's still some kind of race
      between the rendering of the window menu and the window size measurements
      reported by the DOM API-- if we measure too early the vertical measurement is
      too big, resulting in an unnecessary vertical scrollbar.
      So instead we wait 250ms and call do_getscroll after. This apparently
      gives enough time for the menubar to render and for the DOM to take it into
      account when feeding us the window dimensions. But if that race can be fixed
      or worked around, we can change the behavior here to call first then wait
  3. 27 Jul, 2017 2 commits
  4. 21 Jul, 2017 1 commit
  5. 20 Jul, 2017 1 commit
  6. 18 Jul, 2017 6 commits
  7. 16 Jul, 2017 1 commit
  8. 15 Jul, 2017 1 commit
  9. 14 Jul, 2017 1 commit
  10. 11 Jul, 2017 16 commits
  11. 10 Jul, 2017 1 commit
  12. 09 Jul, 2017 2 commits
  13. 08 Jul, 2017 1 commit
  14. 07 Jul, 2017 1 commit
  15. 06 Jul, 2017 2 commits
  16. 04 Jul, 2017 2 commits