Commits on Apr 24, 2019

1. Large items spanning the whole visible range (extended by 25% to the … …

   …left and right as a "buffer zone") are
   
   initially hidden until their start or end scrolls into that range.
   
   This commit fixes this by increasing the buffer zone depending on the items, so that its large enough to fit all *potentially visible* items.
   
   The current implementation has two performance-related drawbacks:
   
   1. As the whole "scanning range" is enlarged, more items need to be processed and more items will be visible. I see no problems for light datasets, but for large datasets with many items - especially item types without end date - this could become a problem.
   Possible solutions:
     a) two scanning passes: first one for items with start and end using the extended buffer zone (as implemented in this patch), a second one for items without end using the fixed buffer zone (as before)
     b) same as a) but items with start and end could be grouped in *some* groups depending on their duration
     c) add an option to choose: have this fix with the performance drawback, or tolerate the bug but with higher performance for large, mixed datasets
   
   2. Maximum duration is calculated per group at rendering level, which happens more often than needed.
   Possible solution: calculate on item changes and cache it. Should be easy to fix for someone who knows the location where this could be implemented without missing any changes.
   
   As a side note, I think the initial buffer zone size should be configurable, currently at 1/2 of visible range (1/4 to the left, 1/4 to the right).

   

   sbusch committed Apr 24, 2019
   Configuration menu

   • View commit details
   • Copy full SHA for 8dfb13f
   • Browse repository at this point

   Copy the full SHA

   8dfb13f View commit details

   Browse the repository at this point in the history