Skip to content

[PORT] Stabilizes code that flicks overlays to view/all clients #6631

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 12, 2025

Conversation

Absolucy
Copy link
Member

About The Pull Request

Ports tgstation/tgstation#76937 and tgstation/tgstation#77155

Why It's Good For The Game

better performance meow

Changelog

no user-facing changes

LemonInTheDark and others added 2 commits May 10, 2025 15:18
Rather then using images and displaying them with client.images, we can
instead simply make an object, give it the passed in image/MA's
appearance, and then vis_contents it where we want.

If you want to animate things, you can just use the atom we return from
the proc call.

This ends up costing about 25% of the best case scenario (one guy
online)
It will save more time with more users, but it also allows us to avoid
the hypersuffering that is passing GLOB.clients into the flick proc. So
I think I'm happy enough with this.

For context, here's average per call cost for flick_overlay_view() right
now.
It winds between 5e-5 and 1e-4. With these changes we should pretty
consistently hit the low end of this, because none of our work really
varies all that much.

![flick_avg](https://github.com/tgstation/tgstation/assets/58055496/3483e022-9cc5-490a-be5e-eb79f4e2110b)

(I was using sswardrobe for this, but it ends up being a lot slower so
like, why yaknow)
```
/atom/movable/flick_visual
        New: 3.65625ms
        Provide: 7.4375ms
        Qdel: 9.4375ms
        Stash: 9.46875ms
```

Using our tools should not make your code eat cpu time for no reason.
Hearers is expensive, iterating clients is expensive, let's not be
expensive.
## About The Pull Request

#76937 introduced a temporary movable `flick_visual` to act as an image
for overlays and whatnot.
this used to be handled by images and i'm not sure whether images were
mouse transparent or were just inheriting parent ID but i'm assuming
since images are kinda virtual (from what i know anyway) they don't
interrupt clicks.
since flick_visual is an atom, it intercepts mouse clicks, which caused
#77142
this PR gives flick_visual `MOUSE_OPACITY_TRANSPARENT` during
`flick_overlay_view()`, which makes it no longer intercept clicks

## Why It's Good For The Game

Fixes #77142 and possibly some other things that use that proc to show
animations or overlays
@Absolucy Absolucy merged commit 05e8131 into Monkestation:master May 12, 2025
26 checks passed
@Absolucy Absolucy deleted the flickify branch May 12, 2025 01:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code: Performance / Optimization the number going down makes me happy :3
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants