ID:2714024
 
Not a bug
BYOND Version:514
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 91.0
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

Using a post-processing effect on some atoms causes clients' GPU to go above 100%.

Client verison: 514.1566
Server version: 514.1566

Numbered Steps to Reproduce Problem:

1. Create atom with KEEP_TOGETHER.
2. Assign it a 352x352 image.
3. Add in a few overlays to that image.
4. Use a post-processing filter.

Code Snippet (if applicable) to Reproduce Problem:
    filters += filter(type = "blur", size = 2)


Expected Results:

The filter to work.

Actual Results:

The GPUs of our players goes above 100%, including very high-end ones like a RTX 3080.

Does the problem occur:
Every time? Or how often? Every time.
In other games? N/A
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?

It does seem to happen even locally as well the correct stress triggers are used.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

N/A

Workarounds:

Not using post-processing.
Follow-up on this: I thought I might have had forgotten to clear up the filters, but this isn't the case.

Even if we explicitly order byond to clear up the image's filters before applying the gaussian noise, it starts to eat all your GPU's processing power and may keep doing it long after you've stopped.

Closing Dream Seeker instantly stops it from computing.
I've never had the blur filter blow up my GPU. Do you have a test project for this? You mentioned it happens on some atoms, but it definitely never happened on anything I tested.

Also, your post title says there's a memory leak but the content says it's just high GPU usage. Which is it?
High GPU usage, sorry, this was an improper term.

A common trigger is to move around an object on which the filter is applied while there are stationary objects on which the filter is also applied.

GPU quickly builds up and heats.

If that helps, all these atoms (the movable as well as the fixed ones) have matched planes and layer.

I will attempt to make a minimal working example tommorow. I must warn that the GPU going at 100% is not an exxageration, so please be aware of that.
I can always shut down the program quickly. There's probably something simple that can be done here. The blur filter is a really basic two-pass deal so I don't get how it'd be able to cause trouble. The large size may be related, if it's having to allocate big surfaces, but generally it should try to conserve those.
Whilst trying to narrow it down to a reproducible case, I found a way around my problem. It looks like the error was on my part: somehow, the filters list was not properly cleared and kept building up.

Changing my code re-arranged that.

I think I just forgot a case where the filters pilled up. Error's on my end.
Aha. Thanks for the follow-up.
Lummox JR resolved issue (Not a bug)