1035548 - IPViking Live, citing performance issues, Only Supports Chrome

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Benjamin Kerensa [:bkerensa]]

Attachment: Screen Shot 2014-07-07 at 5.26.43 PM.png

https://map.ipviking.com only supports Chrome

Comment 1

[sjw]

WFM in current Nightly, but it seems to have a very bad performance.

Comment 2

[Benjamin Kerensa [:bkerensa]]

Works but they give a popup saying they only support Chrome unless you UA spoof

Comment 3

[jtmoulia]

I worked on the IPViking map, and added that message because performance was significantly better on Chrome compared to any other browser. 

It might be possible for it to be optimized for Firefox, but I'm not sure how to best start. Would profiling data be the most useful? Or is there a list of Firefox specific speedups and and gotchas (esp around Canvas) that the code can be checked against.

Thanks

Comment 4

[Karl Dubost💡 :karlcow]

Connecting to https://map.ipviking.com/ with Firefox 32.0.1
raises a 

> "Secure Connection Failed. An error occurred during a connection
> to map.ipviking.com. SSL received a record that exceeded the 
> maximum permissible length. 
> (Error code: ssl_error_rx_record_too_long) "

Trying with http://map.ipviking.com/

I don't see any issues be performance or layout.
Some performance issues happen when there is  massive attack being displayed, but this happens also in Opera Blink. So not sure there is a real bug here.

@jtmoulia 
How did you determine that there was a difference? Which aspects?
If there is really a difference it would be cool to know from where it was noticed and then from there we can drilled down the origin of it. ^_^ Thanks.

Comment 5

[Karl Dubost💡 :karlcow]

Attachment: massive-attack.png

Example of massive attack. Burst of green.

Comment 6

[Jeff Fortin]

There is no more spoofing needed as the website does not block Firefox visitors on http://map.ipviking.com/, but in Firefox you get roughly one frame every *two seconds* (tested with radeonsi and intel drivers on Linux). In Chrome, you get super fluid performance with animations flying all over the place and interactive points being very reactive.

Comment 7

[sjw]

Since this is likely a Firefox specific performance bug I'll move it to Core.

Comment 8

[Jeff Fortin]

You should also retitle for clarity.

BTW, I tested this on Firefox for Windows with a fairly powerful i7+nVidia setup too, same results; YMMV.

Comment 9

[Till Schneidereit [:till]]

Moving to graphics, as almost all time is spent in either Canvas or DisplayList code.

Also, enabling skia-gl on my OS X setup improves things substantially. Which makes me wonder: Jtmoulia, did you test this on Windows? We have hardware acceleration of Canvas2D working there, so it might well be the case that most of your users wouldn't experience the same performance issues that one sees on OS X and Linux.

Comment 10

[Hugh Nougher [:Hughman]]

Just tried Win8.1 with x86_64 e10s Nightly against Chrome. Chrome has at least 4 times the framerate. Full CPU used in content process.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Jeff, Bas, do you know who might be able to look into this?

Comment 12

[jtmoulia]

@till - I haven't ran it on windows yet, I asked my dad to give it a try :) Has anyone else tried this?

Additionally, my contract is up I'm not working on this anymore. I sent the issue to Norse; hopefully they can implement any suggested changes.

Thanks for the thoughts!

Comment 13

[Jeff Muizelaar [:jrmuizel]]

(In reply to jtmoulia from comment #12)
> @till - I haven't ran it on windows yet, I asked my dad to give it a try :)
> Has anyone else tried this?
> 
> Additionally, my contract is up I'm not working on this anymore. I sent the
> issue to Norse; hopefully they can implement any suggested changes.
> 
> Thanks for the thoughts!

jtmoulia,

One of the big performance bottlenecks seems to be the use of getImageData(). Do you know why that page is using getImageData()?

Comment 14

[jtmoulia]

`getImageData()` is used to draw+color to the "particles", however it should be caching each result for a given `(r, g, b, a)`. I believe that's why it's especially slow initially, but speeds up after a little while.

At the moment, I don't have dev access to the code, and am not able to connect to the data source locally so I'm not the best resource :/

Comment 15

[Eyal Kalderon]

Still running into problems with this site in Firefox 37.0.2 x86_64. Any news?

Comment 16

[Wayne Mery (:wsmwk)]

http://map.ipviking.com/ now redirects to http://map.norsecorp.com/

Comment 17

[Karl Dubost💡 :karlcow]

Thanks Wayne.
I tested again in Firefox Nightly 46.0a1 (2016-01-20).
The performances seem to be acceptable. I will close this as worksforme.

If we reopen we need a way to better assess the perf issue and set a criteria for reaching them out.