ID:2141029
 
BYOND Version:510
Operating System:Windows 7 Pro
Web Browser:Chrome 52.0.2743.116
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Keep Together has a very specific problem when used within projects in DM. When keep together creates objects much larger than screen size it causes framerate to slow to a crawl in comparison to the same keep together object made of icons that all fit within the screen.

I made a test case such that this can be demonstrated.
http://puu.sh/qUhCj/d70828eac0.rar

This creates objects with about 400 overlays (which as long as they're in the small form OR keep together is off, will only case a slight/minimal framerate drop), using the verb toggles in game should demonstrate the issue with keep together. To make the turf location markers more obvious, the plane of the very large objects is set below the turf layer.

This issue is significant in that it keeps plane master + keep together based lighting systems with shadowcasting from being effectively used. When this issue is solved, the last major hurdle for their use will be fully cleared.

Numbered Steps to Reproduce Problem:
1. Spawn about 20 objects in my test case (400 overlays each)
2. After framerate settles down a bit toggle keep together on/off, observe no significant difference in framerate
3. With keep together off, toggle object size, which makes their overlays about 10-15 tiles in size and pixelshifted around. Wait until framerate settles down again.
4. Turn keep together on, now with both large object sizes and keep together see a SIGNIFICANT framerate drop in comparison to any of the earlier conditions, even when only all of the images are only slightly in view.

Code Snippet (if applicable) to Reproduce Problem:
http://puu.sh/qUhCj/d70828eac0.rar


Expected Results:
About the same results with/without keep together

Actual Results:
It seems lummox was right in that the most likely problem keep together faces is expanding/contracting view size while its drawing. Or something to that effect anyway.

I think the act of creating a giant rendering surface, and then rendering it onto another surface, is the real issue here.
This is currently a serious problem with one of my projects and it would be very nice if it could be addressed at some point.
This would be amazing, with this we could make this lighting system a reality:



Currently it suffers from performance issues clientside due to this bug.
Performance issues being 'client FPS drops into the low single digits', to be specific.

That said, one of the serious issues with the system as it was when that screenshot was taken was that the corner shadows were internally the size of the entire world.view. More recent iterations have significantly cut down on (but not actually solved) the performance problems by removing the corner shadows and Loganbacca is trialling a system using more specifically sized corner overlays. It'll be interesting to see how much the client performance problems are decreased by that.
The only thing you could do really is try to chunk it up into as small pieces as possible, through either cropping or some other method.
In response to Zuhayr
Hopefully there's a way you can think of to optimise this byond-side, because this really opens a lot of doors for things you can do, as in PJB's screenshot.