Topic: Webmap as browser stress test...

[Bonk]

I have discovered/realised this weekend that the webmap makes a very good browser performance evaluation tool. (as it can ask the ridiculous of a browser)

In updating the OCI with some javascript (sigh, yes I caved) to try and do the zoom calculations client side and all four browsers I tested failed (all could do it, but too slow to be usable). The browsers tested being Iron, Opera, Firefox and IE. (I have yet to try Safari). However, all are able to drag the map within its container. (IE quite slowly though). I'm thinking if I move to a JSON solution then I might be able to get all the browsers to do these tricks client side within cpu constraints. Bear in mind I'm currently testing a 61x29 map (up to ~10000 images, but probably on the order of about 5000). The Forge map is 50x40 hexes (even larger) but the currently posted flatfile map setup places fewer demands on the browser. Nevertheless, browser rendering performance differences are clear on the current flatfile map.

http://www.dynaverse.net/webmap_theforge_ff/
(Just hit the load map button at the defaults and observe the wide range of browser rendering performance.)

My observation in rendering performance from best to worst: Iron > Opera > Firefox > Internet Explorer.  What do you get? (Don't hammer Dynaverse.net too hard - that script is calling the map from eAccelerator cached keys in memory, as reading such a large map from the binary flatfile was a php performance challenge in itself...)

There are more nuanced differences in javascript performance of course.

But wow, this makes it really clear.

Note: only current stable releases tested.

P.S. For those unfamiliar: Iron is a privacy secured version of Google's Chrome browser, both of which are based on Chromium.

I think Iron just became the officially recommended browser for use with the webmap/oci. More testing is in order of course. I may need to round up the beta crew for this one if they feel it is worthy.

[Lepton]

My assumption is that Chrome would be as fast as Iron.  I've been using Chrome for the past week or so and it seems to me to be noticeably faster than Firefox.  On occasion, Chrome has failed to render pages from a major video gaming website and some forum pages, so it certainly is not perfect, but it is pretty fast.

I'd also be interested to know what the comparison would be between using bitmaps like GIFs or JPEGs or vector graphics like SVG.  I know nearly nothing about these issues but I would assume that it would be less intensive to draw some colored lines rather than rendering the entirety of the hex area in a raster bitmap.

[Bonk]

My assumption is that Chrome would be as fast as Iron.  I've been using Chrome for the past week or so and it seems to me to be noticeably faster than Firefox.  On occasion, Chrome has failed to render pages from a major video gaming website and some forum pages, so it certainly is not perfect, but it is pretty fast.

I'd also be interested to know what the comparison would be between using bitmaps like GIFs or JPEGs or vector graphics like SVG.  I know nearly nothing about these issues but I would assume that it would be less intensive to draw some colored lines rather than rendering the entirety of the hex area in a raster bitmap.

Ya, Chrome should be the same as iron. And Iron is only marginally better than Opera, mostly in that it can drag thousands of images more readily. Firefox is noticeably slower and IE is slower still (well its OK on page loads after the initial, but struggles badly with dragging many images).

I did think about SVG, it would make the most sense. But browser compatibility? Do they all support it? It would seem to me that with current technologies a JSON map object and svg graphics would make the most sense. That is a major re-write (which might happen), currently I'm just working on updating the oci's integration with SMF2 (new abstracted db calls - so postgre would work if we make the serverkit talk to it too) and getting a more polished look. It's almost ready, and certainly ready to do the job of debugging the new sfb-op map that I need it to do!

[Bonk]

Add Konqueror to the browsers that pass the muster.

Current standings:

1) SRWare Iron (Chrome)
2) Konqueror
3) Opera
4) Safari
5) Firefox
6) Internet Explorer

Or by Layout Engine:

1) WebKit
2) KHTML
3) Presto
4) Gecko
5) Trident

So Safari ought to work well too as it uses WebKit which is derivative of KHTML.
edit: i just gave safari a test and it performs about on par with opera but just a notch lower (the windows version of Safari anyway, it is probably faster on its native OS)

[Pestalence_XC]

Um.. I run IE 8 only.. once I set the Web map for compatibility mode (rendering map as IE 7), the map loaded in .25 seconds at 50% zoom looking at Empire / defense

.5 seconds for Empire / defense at 100% zoom,

no speed/visual problems at all on my end..

but then again, Windows 7, IE 8, and Cable Internet running 30 Mbps down and 2 Mbps up, 4 GB system memory, Core 2 @ 2.66 Ghz CPU OC'd to 3.86 Ghz.. with NForce 650i SLI chipset and NVidia 8800 GTX OC 2 vid card with GeForce 8800 GTS OC 2 in the SLI position.

Can run near real time with refresh set to every .75 seconds if need be.. so unless those other browsers are "Instant" load, as in < .25 seconds.. IE 8 works fantastic.

[Bonk]

Thanks for the stats Pestalence. Good to know how it runs on a system like yours. Odd that compaitbilty made a difference as the meta tag is the first in the header:

Code: [Select]

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> ... seems they're not telling us something...

Try dragging the map within it's container though (new feature). I have removed the test javascript zoom altogether, IE just could not do it at all, while the others could just manage it. I think it's Chromium's V8 javascript engine that is making the difference here. I see the load more as I'm running a less powerful processor.

Oh, but note that IE does not drag the map object like all the other browsers, it needs an extra click to let go... or it will hang on to the map and follow the mouse with it.

Trust me Pestalence, once you try Iron you'll see that the javascript and layout engines it uses really do perform way better. (while Iron does have its rough spots... mostly text selection and like IE lacks spell checking.)

I'm not saying you have to switch browsers or anything, if IE works well for you that's great. I'm just so impressed by the superior performance of Iron that I'm saying you've at least got to give it a try just to see the difference... well, of course you don't have to... you can take my word for it. (it might not be as noticeable a difference on your machine anyway)

It is not so much load time I'm looking at here but rendering performance. Actually not load time at all. Cpu use on render intensive actions such as dragging the map in its container or moving the entire browser window, or scrolling the browser window, or spanning multiple displays, dragging from one display to another... Webkit/KHTML-V8 simply blow Trident out of the water on this. It is plain fact.

Watch your cpu use as you scroll the window and drag the map around. (make the browser window about 1024x768 to simulate an average users display area so that you will have the need to scroll) Try the same with Iron or Opera. There is a major difference. I get frame tearing with IE, FF and Opera, Only Iron and Konqueror can do it without frame tearing (on my laptop, you know roughly the specs).

I knew you might get yer dander up over this one. I'm being totally objective here, you'll notice my old favorite browser ranks second last. (and I have tested the FF 3.5 B4 and it is no better really)

I discovered all this tryiing to get the webmap to do the zoom calcs client side in javascript.  I can do it, but no existing javascript engine can handle it (with normal user resources available - read econo PCs - your's or Frey's might be able to do it but mine can't and I have to code for the average PC).

I'm tempted to post a copy of the oci with the javascript zoom in it for you to try and see, cuz it just might run OK on a high end PC (or Mac) It would be a bunch of work though...   I do want it to happen... perhaps I'll put the javascript zoom slider back in, and since you've got the cpu to test it... problem is that the slider does not increment properly in IE (does in all the others) But if at some later date you'd be willing to test cpu intensive javascript in Iron/Opera/FF for me that would be great. I got it to the point where Iron could complete a zoom increment in about 20-30 seconds at about 60% cpu usage. If I could get that down to 5 seconds or less at 25% cpu usage or less it might be workable...

I'm looking for browser performance that will allow me to move much of the calculations to the client side (to save round trips to the server - my bandwidth). I also want to move to an SVG/JSON model for the webmap, but I expect it will place similar or greater demands on the cient machine. I don't care which browser will be able to do it. Only that one will be able to (currently none can to my satisfaction - but Iron is almost there).

(sorry for the multiple edits... I do miss my inline spellchecking in FF...)

[Lepton]

Um.. I run IE 8 only..

[marstone]

The webmap drag is a nice feature.

[Bonk]

Hmmm this HTML5 canvas element could be just the thing for the webmap judging by the demos of it I have seen so far.

http://en.wikipedia.org/wiki/Canvas_(HTML_element)

Some demos (chrome "experiments"):
http://bomomo.com/ (works in IE with plugin)
http://experiments.instrum3nt.com/markmahoney/ball/
http://mrdoob.com/projects/chromeexperiments/depth_of_field/
http://www.vectomatic.org/main.html
http://deanm.github.com/pre3d/lorenz84.html
http://onecm.com/projects/canopy

If my cpu can handle that stuff in Iron or FF, then maybe I can use it for a snazzy webmap. Definitely worth further study.

[Sirgod]

I'll try it again today, but I have tried it twice now on FF, and it simply crashes the browser. Chances are it's on my end, or due to the sat. con.

It looks like it starts to form hex's, then nothing. Even then I can't close the window by rightclicking ---- close. Have to Cntrl-alt-del to get it down.

Not sure if others on FF have problems. Gonna check out IRON though today. Have yet to try with IE8.

Stephen

[Bonk]

Ya, that would be Firefox (FF) image rendering performance Stephen, it takes a long time on my laptop, but works (whereas Iron loads it immediately on the same computer, and Opera much better than FF as well.)

However, I have just completed the bare bones of a JSON/SVG javascript webmap implementation: 

http://canada-east.ca/oci/svgtest.php  (CAUTION: CPU intensive after you click "Load map")

And interestingly FF loads this one the best as javascript is the bottleneck with this map and with 3.5 I think they are in the lead. Iron takes much longer and may give timeout prompts... obviously there is much more work and testing to go into the new version, but I kind of like the result so far.

Dragging this one on IE seems to blank the hexes... I expect  this is so as the svg implementation of the Raphael library for IE is a VML hack (check non-straight lines...)

If curious, load your task manager and watch cpu use as the javascript executes on your machine... it is about 60% for about 3 seconds in Firefox for me. Compared to the 200 milliseconds @10% cpu it takes to generate in php serverside. (neglecting data transmission time in both cases, note your browser can fool you saying it is waiting for the server when in fact it is waiting on its own cpu use)

Interesting dilemma.

Off to test it some more in other browsers, then assess feasibility of displaying all the map data in various browsers...

edit: oooh nasty on IE, it only displays on second load and it twists all the hexes. Twisted buggers.

edit2: Hmm Opera 10 handles this one easily as well. Starts rendering faster than FF.

edit3: Safari seems to handle it pretty well too, a bit heavy cpu use on dragging though. FF still on top...

edit4: ah, clearing Iron's cache and trying again, it comes out way on top again. So Iron wins in both Javascript and Image rendering, but firefox can better handle javascript load than image file redering load. Internet explorer is just a mess and so far behind now that it is not even funny anymore. What to do abut that?

Cool to play with tech that challenges the latest browsers, like this other recent test of mine (html 5 video tag with flash fallback for other browsers - currently the video tag only works in FF3.5 - edit actually it appears to work in Iron 3 as well... supposedly it works in Safari too?):

[Bonk]

Messing with a slider to scale the svg paths (zoom the map) I accidentally created this  :

[Sirgod]

That is very interesting Bonk.

I might give this a look see again with Chrome later, or of course Firefox, since I think they had an update lastnight/This morning.

Stephen

[Bonk]

I'm beginning to like this approach as it works better in Firefox than images and gives me way more flexibility in coding the display. I am seeing significant potential here. Hopefully IE will catch up soon.

I am breaking down the code I have now for this JSON/SVG webmap, I think I can make it more efficient. (thus allowing room for more functionality) I think I can make this one real pretty.

That zoom slider needs major work though! lol it is a disaster at the moment. (be prepared for browser crashes if you try it)

So as usual with these projects of mine while still a WIP, it may not work at the time you check it out or if you come back to check my progress then clear your (recent)cache to make sure all the js css and html files are in sync.

[Sirgod]

Dude, everyday a new insight into making things work better.

I'd rather have you having WIP's then Not having the Puzzle solving Bonk we all know and love.

Stephen

[Bonk]

"My builds are so wise"

victory song:
[youtube]http://www.youtube.com/watch?v=jaJBOciP8VM[/youtube]

 

[Bonk]

Safari now has a strong lead.

Raphaël 1.0RC1.4 fixes the incorrect paths display in IE (svg->vml).

I also came across this handy site in my travels on this topic: php.js 

I now have some hard data on the actual performance of the various browsers in the rather demanding task of producing the svg map:

First Draw:
Safari: Draw time: 1.3550000190734863 seconds
Iron: Draw time: 2.177999973297119 seconds
Firefox: Draw time: 2.2160000801086426 seconds
Opera: Draw time: 4.96399998664856 seconds
Internet Explorer: Draw time: 22.17599879837036 seconds

Second Draw (clear map, draw map):
Safari: Draw time: 0.8320000171661377 seconds
Iron: Draw time: 1.4609999656677246 seconds
Firefox: Draw time: 1.9029998779296875 seconds
Opera: Draw time:  2.199000120162964 seconds
Internet Explorer: Draw time: 11.769999980926513 seconds

Zoom (25%->100%):
Safari: Draw time: 1.2820000648498535 seconds
Firefox: Draw time: 2.3589999675750732 seconds
Iron: Draw time: 2.936999797821045 seconds
Opera: Draw time: 8.894999980926514 seconds
Internet Explorer: Draw time: 26.52900004386902 seconds

Wow, kind of surprised Safari came out so far ahead! I expect Konqueror to perform similarly. IE has clearly been left in the dust. Firefox and Iron are about even on this one, with a slight lead for Iron. The other performance indicator not measured is map drag smoothness and cpu use (no easy way to measure - it's kind of a "feel" thing).

Drag performance (rough): Firefox>Iron>Opera>Safari>IE

Not so sure about the php.js microtime fucntion - seems like a lot of decimals. I'm not sure my computer is that fast.

Also starting to dislike the effect of the mootools domready function. I can't seem to display status easily and don't want to wrap all my functions in AJAX functions... sigh. I knew I had put off javascript for a reason. 

edit: Hmmm Konqueror 4.3.00 for windows gives an error on the Raphael library that none of the other javascript engines throw.

raphael.js: TypeError: Attempt to use a non-function object or a value as a function.

Unfortunatley it is rather unspecific - no line number or funtion name in the error - not very helpful. It refuses to draw the map because of this error. Too bad it did not tell me where in the library the error is, if it did I could try to fix it.

[Bonk]

Holy carp! A single instance of IE is using 560MB of memory to display the (JSON/SVG) map! 
P.S. that Firefox session is about three days old with 11 windows and about 50 tabs.

[FCM_SFHQ_XC]

lol, IE must hate you bonk..
 I get roughly the Safari draw rate/time for the webmap in IE7 at 97MB memory(2 addditional tabs open)
On XP Pro 2GB DDR SDRAM, 7800 AGP Nividia card, 1.8GHz Single Pentium 4 Core

[Bonk]

Interesting. I'm testing with IE8 on Vista. I'm not surprised that IE7 on XP outperforms IE8 on Vista.  (Similar hardware)

Thanks for the data! Good to know.  I'm curious what Pestalence will get with his uber-computer!

I've just added planets which increased the time a little, and am now trying to figure out the best way to draw those bases in svg.

[FCM_SFHQ_XC]

Here's a little bit better readout from TaskManager...

[Bonk]

Adding bases now. Tricky little three spoked things. Seems SVG paths do not want to double back on themselves.  I had hoped to draw them as a single path, but that may not be possible. Ugh. I must be missing something or need to take a little break, I've been at this for many hours straight today. I love the look of the planets though. (a 315° gradient in a circle element with no stroke)

[Bonk]

I tried it on IE6 on XP yesterday. I had to kill the task after one minute thirty seconds.

Is there better way than the two approaches I have taken to get a browser to draw thousands of images?

Part of me is saying be done with this, quit farting around and start writing a new dynaverse client for vista in C/C++.

Bing! I just realised we may not need the OP source to write a new dynaverse client for OP, the new vista dynaverse client could just launch OP in analogy to gamespy or sfcdirect? Oh maybe not... mission script type differences... there might be a way to hack it though... see where I'm going?

I'm also thinking of skipping a python scripting interface, do it all in c and use plain text files as mission script templates...

[marstone]

I tried it on IE6 on XP yesterday. I had to kill the task after one minute thirty seconds.

Is there better way than the two approaches I have taken to get a browser to draw thousands of images?

Part of me is saying be done with this, quit farting around and start writing a new dynaverse client for vista in C/C++.

Bing! I just realised we may not need the OP source to write a new dynaverse client for OP, the new vista dynaverse client could just launch OP in analogy to gamespy or sfcdirect? Oh maybe not... mission script type differences... there might be a way to hack it though... see where I'm going?

I'm also thinking of skipping a python scripting interface, do it all in c and use plain text files as mission script templates...

So you are talking about the client side (game itself)?  I can see being able to do the server, as you have code for that.  Porting that over should be fairly straight forward. hmmm.

[Bonk]

I guess the idea was not very clear. Let's see if I can do better:

Basically the concept is to investigate the feasibilty of developing an entirely new Dynaverse client and server that uses the existing OP client binary to resolve battles. Similarly to how sfcdirect uses the command line parameters like gamespy, but that launches direct tcp/ip games. I figure there must be hooks or hacks we could find to launch the existing OP client into a dynaverse script game as host or guest with the appropriate parameters.

Make more sense? Or less?

If it could be done, then I see no reason that both generations of the game (OP and SFC3) could play on the same map as our new server and dynaverse client could mission match according to the users preferred tactical client.

Might be just a brainfart. But I sure like the idea. (could get us a vista compatible dynaverse quicker...)

A peek at the EAW source would be highly instructive as to the possibilty of this.



BUT back to my JSON/SVG webmappy!

BIG NEWS for IE users!
http://www.dynaverse.net/forum/index.php/topic,163388476.0.html

Tested IE8 with ChromeFrame on Vista and.... drum roll please....
Draw time 2.3500001430511475 seconds! (first draw)
With IE using only 22MB RAM and the chrome instance using about 50MB

Install the plugin, clear the cache, refresh the svgtest page, et voila!

 

If this proves stable and becomes popular I'll start plugging the meta tag and installation script everywhere!

[Bonk]

Hmmm.... a replacement for the Raphael library?

http://code.google.com/p/svgweb/

Might be worth a try, I could generate svg from the javascript "directly" using this instead of raphael's vml implementation for IE. Could be faster.  But perhaps they are essentially the same thing?

[Bonk]

I just tested the SVG/JSON map in Firefox 3.5.3 on my windows XP install and it does not run!

Code: [Select]

Error: jsonObj is undefined
Source File: http://www.canada-east.ca/oci/js/jsonmap.js
Line: 122
Interesting. It appears that Firefox interprets javascript differently on different versions of windows. Most disconcerting.

I'll try whatever IE version I have installed while I have my XP install running...

Heh, IE6 gives some ambiguous javascript error permission denied with a line number but no filename. Being line 339 it must be in the mootools or raphael library.

Well, so this SVG/JSON webmap does not work on XP.

See why I always hated javascript so much? It's coming back to me now. It just will not run reliably. Period. Too bad, at this point lots can be done with it, but it still suffers the same problems it suffered in 1994.

Rebooting to vista to see if it still runs, perhaps I fell asleep mid-edits the other night or something.

[Bonk]

Wow, it runs on Firefox on Vista, but not on Firefox on XP.

I have reverted to my previous belief that javascript is pure evil and totally useless. I shall waste no more time on it. Shame, as this had potential.

We need a new client side scripting language for browsers. Javascript just plain sucks.