It seems that TBX has enabled Retina display support since version 6.00, and until now the GUI (or I’d rather say, the rendering engine) doesn’t seems to have changed a lot.
I purchased TBX from around ver.7.3.1 but found TBX is sluggish rendering Map view as the number of notes grow (see my old thread). Someone has also encountered the same issue with me (see this thread). Although some of the responses mentioned that this issue is not common and may only happen in some specific machine models, ironically, I have discovered, that all of my friends using Macbook Pro can meet the same problem. I have tried to install TBX 7.5.6 on my machine (MBP 13-inch early 2015), my girlfriend’s (MBP 13-inch 2018), and other three of my friends (all MBP 13-inch, from year 2015 to 2017), and none of these machines can run @mwra’s Afghanistan-COIN.tbx (see this thread for more information) without poor performance and sluggish response to mouse dragging or map movement. CPU usage can go up to around 150% when in map view.
I bet there must be some bugs or bottlenecks hidden in the rendering engine. I think it’s not a big problem for a modern Macbook Pro to handle a Map view rendering task of around 200 Notes. See Curio.app which does a lot of rendering jobs, but the performance is always better than TBX, with the same number of note entries. I understand that Curio’s notes is not the same thing with TBX’s, but this comparison can still reflex the tendency, that TBX’s rendering engine is not fast enough.
However, I just found a workaround which can boost TBX’s performance of (especially) Map view rendering. That is, simply turn off the Retina Display. One can use softwares like SwitchRes X or QuickRes to decrease their resolutions, like changing 1080P HiDPi to 1080P. One can notice a 2~3X increment of rendering speed, at the cost of a blurry screen. For me, I’ll use 1080P Retina when I’m doing other jobs like coding and reading, but switch back to 1080P (without HiDPi) when using TBX.
P.S. I recalled that around version 7.5.5, a bug that influenced rendering speed of links was discovered and neutralized by the developer, many thanks for that.