[feature] add lazy load init tooltip.

[dimensi]

Feature

Hi, can you add lazy initialization tooltip? If I add tooltip on buttons in rows of table. On 20 rows, i get 20 initializations. It's too many. And can you add auto-destroy please like here https://github.com/Akryum/v-tooltip/blob/master/src/v-tooltip.js#L239. Thx in advance. I lost half fps, because tooltip.js autoupdate positions on scroll.

[hekigan]

That's a very interesting performance issue. I did a test with a 1000 rows to see how it goes. If you just scroll normally, there no performance issue. BUT if you go straight to top/bottom or use the spacebar, indeed, there is a huge drop in frame rate.

I do not like that and I am going to work on it.

[victornpb]

I up that, also why do you have to create an id for every tooltip?

[jardicc]

It makes my UI unusable. It updates css positions on scroll to fast. If I won't be able to find fix then I will replace these tooltips with a different library.

I added console.log() inside getScrollParent and there are 4 logged items each millisecond on mouse scroll event.

So single mouse scroll generates 1326 function calls. So I suggest to update only visible tooltip(s). And with lower refresh rate. And add elements into DOM only on hover or click event.

It gets better for scrolling when I turn off "eventsEnabled" in properties. But there is still lag each time I switch tabs, because it has to initialize 240 tooltips.

[hekigan]

@victornpb the need for the id for tooltip is for the html bit. Since it can be an independent node, it's the the simplest in terms of performance because it avoid doing a lookup to find it.

@jardicc You are making a good point. I believe it will be addressed once I finish the original demand. It won't be lazy loading per say, but create/destroy on usage. It should be way better in terms of performance. I should be done within a week.

[victornpb]

Afaik querying the DOM is more expensive than a object lookup. Anyway you just have to instantiate visible tooltips, then remove them from DOM and any references to it as soon as possible. This will clear the DOM, references and you don’t have to calculate any positioning.

You can have hundreds of tooltips on a page, but you usually will have only a few being active, so it doesn’t make sense to have all of them active all the time.

[hekigan]

@victornpb What is expensive in term of performance is painting and querying/manipulating the DOM. I believe that accessing an element with an ID is inexpensive because you don't need to parse the whole DOM, you have a direct reference to your node (cf: https://stackoverflow.com/a/12515085/3438072 ). That's the reason I first instantiated all Tooltips on creation. The problem does not come from this but from the recalculation of positioning that each of them do when something on the page.

I am working on a local branch for performance enhancement and testing but it takes longer than planned because of personal matters. But no worries, it's the next thing to come out.

[jardicc]

@victornpb Position calculating is still needed because you can hover element and scroll mouse at the same time. So tooltip can be outside of the hovered element if you don't calculate position.

[victornpb]

@jardicc yes but you don't need to update invisible tooltips on scroll. I would not even mount them on the DOM since the more elements you have the slower css computations are in general.

When a tooltip is fired, append it to dom and update only mounted elements, when a tooltip is hidden, remove it from the three, and you don't have to calculate or update its position.

[hekigan]

@jardicc It's been quite a while, but I pushed a new version -v1.5.1- which addresses the performance issue. I can have now more than a thousand tooltips set and there is no drop in performance.

I will not close yet this thread because I did not do the lazy loading part yet.