ID:1918489
 
Resolved
Atoms that are not solid (mouse_opacity=2) and have no icon are no longer "drawn" on the webclient.
BYOND Version:508.1296
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 44.0.2403.155
Applies to:Webclient
Status: Resolved (508.1297)

This issue has been resolved.
Descriptive Problem Summary:

area/invisibility = 101


This simple code, when applied in Severed World, massively increases the performance and overall stability of FPS. For Chance, it actually makes the game playable and more responsive.

It's really odd that areas with no icon are being drawn / attempted to be draw by the webclient. But forcing them to be invisible really helps with client-side rendering performance.
I'm still experiencing some harsh FPS issues, but this at least made the game playable.
I mentioned this to Doohl earlier today after Kaio did some experimentation with DS trying to get larger view sizes to be more streamlined.

It's my suspicion that one of two things is giving performance boosts in this case:

1) The areas are not being sent across the network given an invisibility variable, thus reducing sort overhead.

2) The blank appearances are not being rendered, reducing overdraw overhead.

If #1 is the case, a lot of headway with optimization can be made by not sending any appearances across the network that don't have an appearance that impacts rendering or input, in other words lacking a mouse_opacity setting, lacking an icon set, lacking any overlays/underlays, and lacking any /image objects that are visible to the client.

If #2 is the case, a lot of headway with optimization can be made simply by ejecting earlier when a blank (non-graphical) appearance is encountered. In WebGL/Canvas rendering, overdraw is your enemy.

The way I reduced overdraw in my Webgl renderer that I wrote back in December was by using two separate backbuffers. I would use the zbuffer to my advantage for any tiles/sprites that lacked any transparent pixels by sorting them top-to-bottom and rendering them to a backbuffer I called the rearbuffer. Then I'd render tiles/sprites with partially or fully transparent pixels sorted bottom to top in a separate backbuffer that I called the front buffer.

Then I'd take and render the frontbuffer onto the rearbuffer using the rearbuffer's zbuffer, ensuring that overdraw was reduced significantly and only the partially-transparent pixels were rendered to the screen where they actually would show up.

Since all of this was being done on the hardware in a single pass, it prevented as much overdraw as possible and I'd only have to present a single image to the canvas every frame.

I'd like to point out that by combining techniques for optimizing case #1 and #2 would have the best results.
I think what I need to do is allow areas not to be included in the sort list when their icons are null and they aren't listed as mouse-opaque. I forget if DS is optimizing that or if DS is including them in the list as well.
Performance seems to improve with large view sizes in DS as well when areas are marked invisible.
Hmm, so maybe the webclient is having more trouble with a comparable number of tiles than DS is. But in the webclient's case, I don't think it needs to include the areas if there's nothing to click.
I think it comes down to one of two things wrong with the webclient:

Either there's too much texture swapping going on during draw calls, or too much overdraw happening because of the sorting algorithm you are using.

It makes sense to sort things bottom-to-top when rendering, because that's how graphics look, but you have to remember that every time you place a pixel into a texture at the hardware level, that's gonna take processing time. Modern 3D renderers generally avoid this problem using a front-to-back sorting method and using a z-buffer, which allows the shader programs to eject early. Unfortunately, front-to-back impacts partially transparent pixels, making the pixels underneath them not render because the zbuffer records a pixel being at that pixel position in the buffer.

This means that in order to have alpha values show up correctly, they NEED to be sorted bottom-to-top, but for solid pixels, you can perform much better with top-to-bottom sorting.

Overdraw isn't a big deal with C-based renderer approaches these days, but it's a huge deal with JS-based rendering layers. Generally, WebGL can handle fairly well so long as your fill rate is kept minimal. Mitigating overdraw is one of the best ways to salvage sluggish performance.
In response to Ter13
The big question is how much of any of that I can apply in practice, since we're using StageXL for the rendering.
That's a question.
Lummox JR resolved issue with message:
Atoms that are not solid (mouse_opacity=2) and have no icon are no longer "drawn" on the webclient.