Tags: visjs/vis-timeline
Tags
fix(deps): support UUID v14 and use it in standalone/peer exports (#2056 ) * fix(deps): support UUID v14 and use it in standalone/peer exports Addresses GHSA-w5hq-g745-h8pq in standalone and peer exports where we had pinned a vulnerable version. * fix(deps): update vis-data to 8.0.4 This version supports UUID v14.
feat(#1972): add Swiss french and Swiss german locales * feat (locales): add Swiss french and Swiss german locales * fix: forgot to add to locales constant --------- Co-authored-by: l.schaffner <l.schaffner@tecost.ch> Co-authored-by: Alexander Wunschik <alex@wunschik.net>
feat(timeline): Implement new options 'horizontalScrollKey' (#1670, #… …1323) and 'horizontalScrollInvert' (#1595) (#1852) * feat(timeline): (History.md: FEAT-3162) Implement new options 'horizontalScrollKey' (#1670, #1323) and 'horizontalScrollInvert' (#1595) to allow bi-directional scrolling modified: lib/timeline/Core.js modified: lib/timeline/Range.js modified: lib/timeline/optionsTimeline.js modified: types/index.d.ts * feat(timeline): (History.md: FEAT-3162) Document and add examples for new options 'horizontalScrollKey' (#1670, #1323) and 'horizontalScrollInvert' (#1595) new file: examples/timeline/other/biDirectionalScroll.html modified: examples/timeline/other/horizontalScroll.html new file: examples/timeline/other/horizontalScrollInvert.html * refactor(lint-staged) Core.js, Range.js, optionsTimeline.js, index.d.ts * feat(timeline): (History.md: FEAT-3162) Document 'horizontalScrollKey' (#1670, #1323) and 'horizontalScrollInvert' (#1595) `docs/timeline/index.html`. modified: docs/timeline/index.html * docs(timeline): fix syntax error in horizontalScroll example * docs(timeline): remove duplicated block of code in horizontalScroll example This likely happened during merging. * style: reformat * refactor(timeline): remove unused function params * docs(timeline): only invert horizontal scroll in inverted scroll example * docs(timeline): use minified bundles for consistency accross examples --------- Co-authored-by: Tomina <tomina@vycital.eu> Co-authored-by: Vis Bot <visjsbot@gmail.com>
feat(timeline): improve stack function performance (#1847) * Update _traceVisible to preserve item order The return value of _traceVisible is frequently passed to performStacking. performStacking performs better based on how close the ordering of the input array is to ascending start times. Prior to this change, half of _traceVisible's output would be ordered consistently with the input order, but half would be reversed. After the change, the output order is consistent with the input order. Testing in Firefox on a 6,000 item dataset with no custom order function showed that this change reduced stacking time by a modest ~5%. When a custom order function was provided, no performance improvement was measured. * Remove expensive uses of Array.slice When I wrote #1281 I was under the impression that calling `Array.slice` and then using the resulting array in a read-only capacity would be optimised by JS engines to use an offset/crop into the same memory as the original array, similar to how Node's Buffer.subarray works. I have since discovered that this is not the case: in both Chrome & Firefox,`Array.slice` always carries the cost of shallow-copying the array. Avoiding the use of `slice` significantly improves stacking performance with large amounts of items. (On a dataset of 6,000 items, this reduces stacking time by 5-20%!) * Keep visibleItems array sorted performStacking performs better based on how close the ordering of the input array is to ascending start times. The input to performStacking is derived from the Group.visibleItems array. This array is sometimes sorted by start time (for example, when items are added to it via the _traceVisible method and this method was given orderedItems.byStart as an argument). But other times (such as when _traceVisible is given orderedItems.byEnd, or when the _checkIfVisible method is called) items are not added to the array in any useful order. This change keeps the visibleItems array sorted by start time. In a dataset of 6,000 items with no custom ordering, I measured a 1-4% reduction in stacking time from this change. * Fix performance bug in stacking algorithm This fixes several bugs and oversights in the stacking algorithm. None of these affected accuracy but they did affect performance. - Since the horizontalOverlapEndIndex value is precise (unlike horizontalOverlapStartIndex, which is a conservative approximation) we don't need to check each item's start in the `filterBetween` call. - previousEnd was never set, which meant that the horizontalOverlapEndIndex would never be moved backwards. (This was not noticed earlier because the previous oversight hid the resulting issues.) - There was a capitalisation typo (`horizontalOVerlapEndIndex`) but it was in code rendered unreachable by the previous bug. - There was an off-by-one error where inserting an item into an array made the tracked indexes incorrect. The impact of this was also not noticed due to the previous bugs. Overall this commit on average reduces stacking time by 4% when a custom order function is in use (tested with a set of 6,000 items). There is no change when a custom order function is not provided. * Update uses of var to let/const * Fix typo introduced in conflict resolution
fix(timeline): significantly reduce unexpected vertical jumping when … …moving the timeline (#1677) * Significantly reduce unexpected vertical jumping when moving the timeline * style(timeline): remove unnecessary indent change --------- Co-authored-by: Joshua Walsh <josh@ymindustries.com> Co-authored-by: Tomina <tomina@vycital.eu>
PreviousNext