BYOND Version:510
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 51.0.2704.79
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary: Frame rate/performance seems to drop when multiple objects with maptext and overlays/underlays are present in view. This is only tested in Dream Seeker.

Numbered Steps to Reproduce Problem:
1. Launch the test project.
2. Execute the test verb.
3. Walk around as the test verb runs.
4. Observe the game's frame rate/performance.

To see the difference in frame rate/performance, comment out the section of problem code and follow the reproduction steps again. The frame rate/performance drop is not nearly as bad, if present at all.

Code Snippet (if applicable) to Reproduce Problem: Test Project

Expected Results: I expected the game to run at maximum performance and not for a few objects with maptext + overlays/underlays to slow down the client.

Actual Results: A few objects with maptext + overlays/underlays within view slow down the client until they are disposed of. The client's performance returns to normal shortly after.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes; successfully reproduced in a test project.
In other user accounts? N/A
On other computers? N/A

When does the problem NOT occur? When the problem section of code (pointed out in the test project) is commented out.

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

The problem did not occur in 510.1323. The problem started in 510.1325.

Workarounds: N/A
I downloaded your test project, but it only contains the .dme file.
In response to Lige
Lige wrote:
I downloaded your test project, but it only contains the .dme file.

The Build options seems to be broken.

Reuploaded the source.
...Bump. If I did not provide enough information, let me know.
I'll see what I can find.

I'll have to do profiling to suss this out further, but I suspect there are two possible causes: 1) All maptext now uses KEEP_TOGETHER inherently on itself plus its main icon, and that may be a factor. (I'd like to change this for cases where there's no icon at all.) 2) Parsed maptext has never been cached, which all things considered probably isn't great. I don't see how 510.1325 could have introduced a problem here, though; there was a fix to maptext in that build, but it shouldn't have had any impact at all on performance.

[edit 2]
Oh gads, I see your width and height are 256. That's going to have some impact. However changing it to 64x32 doesn't do nearly enough to improve things. I'd bet that maptext parsing is the bugbear here.
Any progress on this by chance?

I reduced the width/height of the maptext to 64x32 and performance is about 50% better if I had to estimate; the slowdowns I used to get aren't as drastic, but are still evident. Gains are even better when playing the game with all other windows minimized. It's the most apparent the first time the maptext is seen during a session.

But yeah, you could probably get away with leaving this alone for now and putting it on the back-burner. It'd still be great if you could figure out some type of improvement here to introduce in the future though.
(Is secretly hoping there is a problem with keep_together that can be fixed so it has great performance)
Caching maptext is one of the items on my list for later in 511.
Elora was using maptext with 4 objects on each maptext object acting as the outline and I had around 30 or so strings and it caused the game to be unplayable so after removing the outline effect it sped up the menu and MouseMove() by like 500%
That's exactly the kind of thing I hope to fix with caching.
Are we sure there isn't some inherent problem with the way KEEP_TOGETHER is done entirely and that this isn't just symptomatic of that issue?
Maptext is the specific problem here; I've seen profile data to confirm it.
In response to Lummox JR
Lummox JR wrote:
Caching maptext is one of the items on my list for later in 511.

Very nice! I'm sure a many will benefit from this. It's a bit surprising I haven't seen more talk about this issue before myself.