Hi hello here are some tooltips that heavily abuse browser controls to allow for an extreme amount of customization. With this library you can have tooltips appear either on object hover or click. By default they will auto-size according to content and clear themselves at any resize or player movement event, as well as auto-position within the main map area while respecting boundaries.
Included is a little demo world to try out the various flavors and settings, as well as two starter "styles" to showcase the UI customization (handled by CSS).
Oh and for actual usage, most of the documentation is in a code-block at the top of tooltips.dm.
Caveats:
- This is still fairly experimental so don't be too surprised if stuff gets JANKY.
- Due to Byond's continued reliance on IE for browser controls, it probably wont work in old IE versions (below 9 I believe).
- There are some confirmed reports of very rare bugs resulting in "squished" tooltips (auto-sizing not doing it's job) and equally rare stuck hover tooltips (mouseexit/mouseover events not doing THEIR jobs) that I'm still debugging.
ID:2249112
 May 20 2017, 10:00 pm
|
|
|
May 21 2017, 2:55 am
|
|
Somepotato
 |
this thing is p ok
|
this thing is actually v ok
| |
v3: Hotfix
- Clicks on non-form elements within a pinned tooltip will now move focus back to the map area. | |
The main issue is that when you display a GDI/GDI+ element over top of a map control you destroy client performance. This includes browser elements.
| |
That is largely mitigated by the current behavior of hiding on mob movement (avoids large map redraws underneath the tooltip), which limits the potential "up" time of any given tooltip fairly effectively.
| |
While they will help a bit, simply having the controls existing at all, hidden or not, will cause issues. Once those things exist they're gonna start hurting client-side performance, especially on older systems. Even your 'size helper' browser is going to hurt it.
For instance, on this older computer I'm on, the thing barely runs, just starting it up and sitting there has it running at around 75% CPU, opening a tooltip causes it to race to 100% until the client is closed, hiding the tooltips won't cause performance to be recovered because they still technically exist, they're just hidden. This will become more of an issue over time if multiple tips are shown and hidden at the same time and things of that nature. It's a really cool way of doing it though, works pretty great for what it's meant to do. It's just not going to be the most useful thing in a production environment because it won't work for everyone and those it does work for will suffer performance hits because of it. | |
It also never frees up the memory the windows are using, if you watch it in task manager and use the hover tip you can watch the numbers steadily increase but never decrease (I don't think there's actually a way to delete a created window)
| |
Yeah that's fair, I didn't go into this experiment expecting stellar performance in fairness. Although I do have to take the chance to critique whatever complete toaster you are running (I've been running this on a production game server for several months without complaints of client lag, especially not 100%-ing anything).
However I do agree that the whole situation is not ideal. Perhaps Lummox could use it as a benchmark for interface improvements in the future? Who knows. | |
Oh, it's super old and shouldn't be accounted for anything.
I think the biggest issue with local testing is that the client and server are both working on the same resources and performance hits tend to show up a lot worse in those cases. The only issue pure clients would really notice are small spikes and a gradual increase in client memory usage. Since SS13 reboots every round there's not a ton of time for the issue to compound too greatly, but if you took it to something that runs for days or weeks at a time you'd have clients who have been logged in for a long time starting to notice their clients running at more CPU than it ever should and using a lot more memory than it should. Eternia actually had the same problem, our admin panel buttons were just that, GDI buttons on top of the map that were shown/hidden as needed, the problem was that those buttons existed for every client, and despite being hidden they accounted for a massive drop in performance because they always existed and were on top of the map (didn't help it was updating beneath it, but that really just makes the problem glaringly more obvious). Once I moved those to their own little window (a bandaid until I can make a more proper replacement panel) client-side performance and memory usage jumped dramatically. Then I noticed I had a browser window sneaking around doing the same thing, removed that, and bam, another massive performance jump. I think the most major issue is that the browser windows aren't actually being destroyed, so they can account for an increasing curve of performance loss the more they're used. | |
different view sizes like "19x15" for example, show the tooltips at wrong positions, how do I fix that?
| |