985158 - (Glow:DLVisuals) Map Visualization & Performance

Status: VERIFIED FIXED

(Websites :: glow.mozilla.org, defect)

Description

[Ben (:bensternthal)]

This bug tracks implementing the download visualization. The exact details are contingent on John Slater's design.

We suspect this will contain:
- Word Map
- World Map With Overlay Of Country & City Downloads
- Ability to zoom in / out

Comment 1

[Ali Almossawi]

Map is hooked to dev data from pmac et al and shows glows and top issues. Choice distribution per continent is pending and is expected to be done by tomorrow.

Comment 2

[Ali Almossawi]

Setting to resolved, as I have implemented the spec for the Maps visualization. I'll create additional bugs for the expected tweaks and tune-ups in the coming week.

Comment 3

[Ben (:bensternthal)]

Reopening so that the scope of this bug can also include performance.

We noted high CPU usage when viewing the map and are looking into ways of increasing performance.

Comment 4

[Ali Almossawi]

Having committed all outstanding tasks today, I'll spend tomorrow looking into this.

Comment 5

[Ali Almossawi]

Ben, Josh,

I'd appreciate your input on the thoughts below.

I've done a few tweaks locally that have resulted in a slight drop in cpu usage. Given that we're aiming for a non-negligible reduction in cpu usage, however, e.g. say an order of magnitude, we'll either need to reduce the number of repaints, an opinion corroborated by Chrome's Timeline, or switch to animating the glows using canvas. Hence, as I see it, the two options for mitigating the performance concern are as follows:


1. Show a subset of geos on the map for which we have a high-count of downloads per minute, with a smaller subset of lower-count geos fading in and out during the length of that minute to maintain the sense of ongoing activity. An on-screen toggle would allow users to switch between the set of all geos and the subset of high-count ones. The toggle would be labeled with icons to avoid having to localize it.

Since our glows encode binary values right now, i.e. "a download", the advantage of this method for the user is that it becomes more apparent by default which cities are engaged the most. Seeing more detail then becomes the result of a conscious decision on their part rather than an imposed state. Moreover, the entered state is one that they would be able to exit from at will if they find it too taxing on their machine. The advantage for us is that we do significantly fewer repaints. Our map would also be in line with the data visualization mantra of "overview first, details on demand."

Having tested this locally, I can confirm that the reduction in cpu usage is significant and the user experience, in my judgment, is not impacted. The map, by default, becomes a leader's board of sorts, and the toggle in turn allows it to function as originally desired.


2. Overlay a canvas on the map and repaint that every second.

I expect that this option will be somewhat cumbersome to perfect and to get things like responsiveness working. I've not worked with canvas before, so there would be that risk. If, however, it is deemed that showing the entire set of glows at all times is a necessity and that the first option is not a desirable one, we can go down this path.


Let me know your thoughts.

Comment 6

[Josh Mize [:jgmize]]

I think that option 1 is clearly the safer route, but I would like to offer a couple of alternatives that may be worth pursuing: in https://github.com/mozilla/mrburns/blob/master/mrburns/main/static/js/map.js#L288-L299 I see that we are using the jquery animate. I think that we could get significantly better performance by utilizing either css3 transitions or a d3 timer based solution instead.

Comment 7

[Josh Mize [:jgmize]]

(In reply to Josh Mize [:jgmize] from comment #6)
> I think that option 1 is clearly the safer route, but I would like to offer
> a couple of alternatives that may be worth pursuing: in
> https://github.com/mozilla/mrburns/blob/master/mrburns/main/static/js/map.
> js#L288-L299 I see that we are using the jquery animate. I think that we
> could get significantly better performance by utilizing either css3
> transitions or a d3 timer based solution instead.

Upon further review I see that you're already using css transitions via d3 in https://github.com/mozilla/mrburns/blob/master/mrburns/main/static/js/map.js#L357-L397 where the most intensive work is being done, and the other section of code was only for the counter, so switching that probably won't buy you as much as I hoped. :(

Comment 8

[Ali Almossawi]

Indeed, the counter animation's contribution to the issue is slight, but I've nevertheless tweaked it (on local), which has improved things.

Comment 9

[Ben (:bensternthal)]

I would support version 1, you will need to double check with John S on any design changes - adding of the icons.

However I think exploring option #2 is definitely worth it. I am not sure how difficult this would be to convert the existing D3 code. D3 looks to not care about svg or canvas but I know its not a trivial conversion.

I would also support if you wanted to take a day to investigate the Canvas approach for feasibility before committing one way or the other.

Comment 10

[Ali Almossawi]

Ben,

It's looking good. I've redone the glow animation in canvas and just need to tweak the fade in/fade out transitions so that they look like our current ones, and fix a couple of quirks.

I'm aiming to have it in a PR by the end of day today.

Comment 11

[Ali Almossawi]

This PR will be merged into master shortly: https://github.com/mozilla/mrburns/pull/90

As mentioned there, I expect that a good number of hours to come will be spent tweaking and tuning things, until we strike a balance between aesthetics and cpu usage, so don't be alarmed if you don't notice a significant drop in cpu usage just yet. Having that said, the improvement on my and Steven's machines is significant, both in terms of cpu usage and in terms of the website's general responsiveness.

I've set aside a few hours tomorrow to go over everything with fresh eyes and make sure that things are as optimized as can be, in time for QA on Monday. If you do notice any bugs, other than the one known issue mentioned in the PR, please let me know. Thanks.

Comment 12

[Ben (:bensternthal)]

This is looking really good and is a huge improvement. I will spend more time testing this afternoon. Nice job Ali!

Comment 13

[Ali Almossawi]

The two outstanding issues have been merged into master and deployed on dev. A few minor changes made to the repaint function ought to make the performance improvement even more apparent.

https://github.com/mozilla/mrburns/pull/91
https://github.com/mozilla/mrburns/pull/92

Comment 14

[Rebecca Billings [:rbillings]]

This looks good to me. Please resolve fixed unless there is something else that needs to be done.

Comment 15

[Ben (:bensternthal)]

Resolving this as I do not see us making additional improvements prior to launch.

Comment 16

[Rebecca Billings [:rbillings]]

Verified