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.

Performance seems to improve with large view sizes in DS as well when areas are marked invisible.

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.

That's a question.