Detailed benchmarking while investigating #100 resulted in the following stats:

I basically just hacked this into LibQTip to find out where they're spending all the CPU time, and the result is... not good:

Both of these parts ultimately come down to calling a bunch of Blizzard widget API functions, like setting anchor points and using FontStrings. The problem here is that we can't change those, and clearly most of the time is spent going from Lua to C++ and setting the Regions and their properties.

This is unfortunate because it means there's no way to speed up the tooltip rendering significantly from the Lua side of things, not even by hacking LibQTip itself. Instead, a better approach (that I thought of much earlier) would be to build the tooltip once and then only update the relevant lines. That way, it would take some 500 to 800ms on load and negligible costs to update individual lines. This, of course, is impossible with the current GUI architecture, so a major rework is needed.

An alternative idea would be to use an approach similar to Blizzard's FauxScrollFrame, where only a small number of items are displayed and the contents update dynamically based on the frame's scrollbar position. I'd need to look into this before I can decide whether that's actually a workable solution or even possible in this case, however.

As an example for the FauxScrollFrame approach, we could take a look AddonControlPanel. This would mean having to create the MainWindow from scratch (which might even be a good thing...), but it should be possible using Blizzard's FauxScrollFrameTemplate.

That is at least worth looking into before deciding on whether streamlining the LibQTip integration or a different UI built from scratch would be easier.

This is essentially the way to fix #136 and #120, so maybe it would be prudent to focus on isolating the tooltip functionality first.

Code: https://gist.github.com/Duckwhale/ea24e457155b13d89968c854c10447f8