Nits

Aslan Tlaukhu (or however you spell it) bloc allegiances for A0-A9 should show up in SEC output now.

Also, I made a tweak to how "render slop" works. This will either improve performance/stability a bit, or lead to missing data in certain tiles. Let me know...

Data Updates

Just some data updates:

• c/o Mark Humphreys, updated data for Ricenden, Gzirr!k'l, and Centrax, and new data/metadata for Wrenton and Porlock in Hiver space
• c/o the newly relocated Traveller Wiki, added subsector names for Itvikiastaf and Tuglikki

Performance Fixes

To try and improve the stability and responsiveness of the site (sill hovering at about 99.6% which is okay but not great) I grabbed a trial copy of the ANTS Performance Profiler and did some CPU and Memory profiling. Good news - there was some low-hanging fruit that may explain some of the issues. All of it came down to non-obvious behavior in the PDFsharp library I use as an intermediary for rendering to bitmaps and PDFs.

• GPU: Each transform applied to the graphics state resulted in two matrix multiplies. In many cases my code was stacking up to 5 transforms before rendering anything (scale, rotate, translate, rotate again, scale again...). This showed up as a CPU hot-spot. This was greatly reduced by composing the matrices locally then sending the final matrix into the graphics context.
• Memory: Every text operation (DrawString, MeasureString) resulted in the allocation of several temporary StringFormat objects. Just a few seconds of panning around the map would generate 3MB of such objects - even more than temporary strings and at least an order of magnitude more than any other memory churn. They would all be GC'd eventually, but under load this could have caused the site to blow past the application memory pool limit resulting in a reset. This was fixed by changing PDFsharp to re-use the default objects and I reported the issue to the maintainers.

The remaining major CPU hot spot is, unsurprisingly, in clip path intersections for borders and sector boundaries, which is probably the most subtle and complex part of the map rendering process. Unfortunately, it will be hard to optimize directly but I can probably reduce the need to do it in the first place, e.g. more aggressively pruning which borders to render for a tile, and only doing sector edge clipping if there's a border that goes outside the sector in the first place.

I'm hoping that above fixes will result in higher site availability - I'll be watching my monitoring service (Pingdom) to see if they've made a material difference.

By the way, the ANTS profiling tools are quite nice. There's one for Memory and one for CPU. Like most profilers they work by attaching to your process and recording what functions are taking time (for CPU) or what objects are being allocated/freed (Memory). The ANTS tools integrate very nicely with ASP.NET - I was able to just point them at my development directory and say "go" and they launched a dedicated web server and browser so I could generate some traffic. The results are also really easy to understand - there's the traditional drill-in display that shows you inclusive time for each function, but also a source display and interactive call/allocation graph. Very effective!

UPDATE (2013-04-07):

Just to show how helpful profiling tools can be: I was investigating the border clip path logic and found a flaw in the "selector" code which helps determine which sectors are "in view" when rendering a tile. It was under-computing the number of sectors overlapped by a tile. Fortunately, there's already a 1-sector "slop factor" that's necessary so that e.g. routes or labels that cut across a sector's boundary are rendered, so this bug never manifested as missing content. Unfortunately, the correct code meant that even more time was spent on border path clipping (c/o the ANTS CPU profiler).

Borders are a special case where they are always clipped to the sector bounds anyway, though, so I rather than relying on the expensive clipping operations to do the right thing I added a simple bounds-intersection test. This cut border rendering from nearly 55% of the time of a typical tile rendering pass to only about 15%, under the overhead for drawing worlds (about 22%). This should also help with site stability.

New T5 Data Drop

Another T5 Second Survey data drop from Don McKinney. This one rolls in updated data for Ziafrplians and Gvurrdon, and fixes a few glitches like extra TL-G worlds that sharp-eyed users have noticed.

I've also rewritten parts of the page that display dynamic data - search results and the credits/links at the bottom - as well as the booklet generator to use Handlebars.js. I had been using JsonT but wanted to move to a more modern template system. Handlebars is derived from Mustache but supports paths which I needed. This should not have changed anything except for a slight performance improvement, but as usual let me know if I broke something.

Labels, Retina, and Theta Borealis

Some minor but shiny stuff:

• Display updates and animations now use requestAnimationFrame if supported, and I used Chrome's developer tools to look for hot spots and removed some inadvertent forced layouts in loops, which should mean lower CPU load and "reduced jank" when panning the map.
• Thanks to 77topaz for pointing out that I'd broken the map in older versions of IE. A quick fix to me requestAnimationFrame polyfill and the map should be happy in IE9 again.
• I tweaked the presentation of polity labels seen when you first load the page - they wrap so they're a little more readable now. Sector names now wrap too, which more closely matches the Imperium Map poster. I was also able to bump up the font size. In summary: the initial view of the map should be prettier.
• If you view the map using a modern browser that supports devicePixelRatio on a device with a high-density ("retina") display, such as an iPhone 4S/5, iPad 3, newer MacBook, Android, or even the shiny Chromebook "Pixel", the tiles are now rendered with higher quality. Summary: more pretty!
• On a retro kick, I swapped in the data, borders and routes from Group One's Theta Borealis Sector supplement. Watch out for the Zerp! Note that the double worlds in the original's hexes 2901 and 2118 are not shown on the map and won't appear in the data.



Original - Group One	TravellerMap.com