Framerate in a browser

[Nick]

Hi all,

I'm trying to display application statistics and diagnostic information (e.g. framerate) in a web page, updating it in real time. Anyone know what technology I could use for this?

I'm currently already using WinSock 2 to directly open a socket and serve a web page with controls to modify application behavior. But it requires reloading the page to exchange data. For an FPS counter and such I was hoping it could continuously call a function on the server side and update the text field without reloading. Note that I'm trying to keep this as lightweight as possible. Any ideas?

Thanks!

Nicolas

[TheNut]

I take it your custom web server is very simple? Otherwise I would have suggested using AJAX calls to exchange the data. This would be your most lightweight solution, next to using a more sophisticated solution such as Flash or Silverlight.

[alphadog]

I think I need more details on your architecture. What is your client built from? What's on the server side?

[Nick]

I take it your custom web server is very simple?
Yes, I simply open a socket and send the web page as a string. :happy: And I'd like to keep this as minimal and low overhead as possible.
Otherwise I would have suggested using AJAX calls to exchange the data. This would be your most lightweight solution, next to using a more sophisticated solution such as Flash or Silverlight.
I started looking at AJAX, and it seems like it's just a collection of standard technologies used together. So possibly something as simple as a framerate counter could be done with little extra code. I'm baffled by all the advanced uses and derived technologies though. Many tutorials assume you're using high-level tools, while I'm trying to understand it at the lowest level... :surrender

Anyway, thanks for the suggestion! If anyone knows where I might find essential information about this technology or something similar that would be much appreciated.

[alphadog]

AJAX is a big world of lots of differing technologies and frameworks that operate at different levels.

But, at the core, it is a browser's use of asynchronous calls, via Javascript, using an in-browser object (XMLHttpRequest (http://en.wikipedia.org/wiki/XMLHttpRequest)) such that the browser can send and retrieve information. Typically, this information is then used to alter the browser's DOM. That's AJAX at it's core...

[Nick]

What is your client built from?
Any browser.
What's on the server side?
A full-screen application opening a socket and listening for HTTP requests. It sends HTML pages as an ordinary string, containing several basic controls such as checkboxes, drop-down lists and buttons. When changes are posted the server can parse the control settings and pass these on to the actual application.

I've used this in SwiftShader 2.0, to control quality settings interactively (and remotely). Now I want to reuse that for a new project and extend it with real-time diagnostic information.

[alphadog]

If you focus on finding tuts on how XMLHttpRequest is used to support AJAX ideas, you'll probably find what you need.

Edit: Get familiar with low-level, cross-browser issues. Most of the AJAX libraries are made for app-building and encapsulate all the nitty-gritty for this.

[Reedbeta]

Here's (https://developer.mozilla.org/en/AJAX/Getting_Started) a decent low-level article showing the client-side Javascript needed to send an asynchronous HTTP request and parse the result. You can certainly use this to download some information from the server and update the page without reloading it. XML is used because it's easy for Javascript to parse. On the server side, you just need to listen for the requests and dump out the requested data.

[alphadog]

Here's (https://developer.mozilla.org/en/AJAX/Getting_Started) a decent low-level article showing the client-side Javascript needed to send an asynchronous HTTP request and parse the result. You can certainly use this to download some information from the server and update the page without reloading it. XML is used because it's easy for Javascript to parse. On the server side, you just need to listen for the requests and dump out the requested data.

That reminds me. Ignore the 'X' in 'AJAX', Nick. :) If anything, you want to look at JSON, but it seems like your server-side code send HTML fragments already?

[geon]

You could try using Comet for updating the stats. You would basically send new data to the browser continuously, overwriting the old. The easiest way is to send immediate Javascript like

<html>
<body>
<script type="text/JavaScript">
document.write("FPS: 0.23")
document.write("FPS: 0.24")
document.write("FPS: 0.21")
document.write("FPS: 0.23")

(...)


Each "document.write()" will overwrite the content of the browser window. You probably want something more sophisticated, like

var MyElement = document.getElementById("SomeID");
MyElement.innerHTML = "FPS: 0.23";
MyElement.innerHTML = "FPS: 0.21";
MyElement.innerHTML = "FPS: 0.25";

(...)

NOTE!!! Some browsers will not update unless they have recieved some minimum ammount of data. (like 1kB or something.)

[Nick]

AJAX, DOM, XML, DHTML, XHTML, JSON, Comet... any more acronyms that will make my head explode? :blink:

Thanks for the suggestions using XMLHttpRequest! It looks like that's the vital part for creating dynamically updated content. I assume it's no big deal to make JavaScript contact the server at fixed intervals?

[alphadog]

Yeah, welcome to a new acronym soup. :)

If you are trying to keep it absolutely dirt simple, then all you need to look at is the Javascript timer ( window.setTimeout() ) for polling your server. Careful with this though. All that polling can turn into a self-inflicted DDOS pretty quickly. Consider finding a way to do updates based on some client-side event, if possible, rather than on a fixed interval.

Essentially, COMET (http://en.wikipedia.org/wiki/Comet_%28programming%29), like AJAX, has a big name, but at its core is the same XHR object plus polling.

Added: I think the main distinction is that COMET uses long polling, which means keeping the client connection in waiting. So, instead of "are we there yet?", "no", "are we there yet?", "no", "are we there yet?", "no" ... "are we there yet?", "yes!", you have "are we there yet?" <wait for a long time until Dad has an answer, could be one minute, could be one hour> "yes". :)

[Reedbeta]

I assume it's no big deal to make JavaScript contact the server at fixed intervals?

Not at all; you can use Javascript's setTimeout() function to schedule a function call in the future.

[Mihail121]

Hm, a somewhat simple solution with complex tools would be to include a stream control and feed it data. Like a MediaPlayer stream. Of course, this requires overhead to generate the stream server-side.

[TheNut]

Just remember that you enter the realm of browser wars ;) IE does their thing, mozilla and the rest do theirs.


// For Firefox, Opera 8.0+, Safari, use
new XMLHttpRequest();

// For IE, use
new ActiveXObject("Msxml2.XMLHTTP");

// For older versions of IE, use
new ActiveXObject("Microsoft.XMLHTTP");


They all carry the same API though. I just use a try/catch ladder and keep going until one of them works.

[Nick]

Got it working! :yes:
Ignore the 'X' in 'AJAX', Nick.
Yes, exactly. All I needed on the server side was to write the FPS value as a string in an ordinary HTTP response, and on the client side it pops out as the responseText property of the XMLHttpRequest object. The remaining piece of the puzzle was to assign it to the HTML text field using DOM (http://www.w3schools.com/htmldom/dom_methods.asp).

Thanks all for the help!

[Nick]

Got one more oddity...

First I was using the URL http://localhost:8080/configtest for the web page, and http://localhost:8080/configtest/fps for retrieving the FPS (i.e. the URL passed to XMLHttpRequest.open). Everything worked fine. Now I'm trying to change "configtest" to another name, and the browser hangs. No exception thrown, no error message, just 100% CPU usage.

I've checked like a hundred times that I replaced "configtest" everywhere. I was also able to verify that the request reaches the server, the URL is the correct one, and it sends the HTTP response containing the FPS. It just appears to never arrive. I've fully disabled my firewall but it still hangs.

Any clues? :huh:

[alphadog]

Hmm, without knowing more details on your custom stuff, it's hard to tell. Did you try different browsers? Did you try an HTTP analyzer?

[Nick]

I fixed it using HTTP POST instead of GET. It probably has something to do with the way GET requests are cached by the browser itself. The first GET request fails because the XMLHttpRequest object isn't completely ready yet, and for subsequent calls the browser appears to assume it has to repeat that error code. :wallbash:

Anyway, I'm glad I got that fixed, but I already discovered a new issue. It works fine using Internet Explorer (8), but not using FireFox 3.5. I get the FPS once and then it freezes. I guess I can use Venkman to attempt to debug it. If anyone has any guess what the issue could be please share.

[geon]

Nick, if you want to do more than just the simplest javascripting for a single browser,you REALLY should look into something like jQuery.

It abstracts away most of the retarded browser differences and annoying API:s.

If you are into functional programming, you will appreciate the jQuery API.

[Nick]

Nick, if you want to do more than just the simplest javascripting for a single browser,you REALLY should look into something like jQuery.
Looks interesting for a lot of purposes, but it's not an option for what I'm doing. I'm writing my own extremely light-weight HTTP server, and I have no intention to even make it handle file retrieval. All it has to do is serve a string containing basic HTML and embedded JavaScript...
It abstracts away most of the retarded browser differences and annoying API:s.
Yeah, I noticed there can be a few differences in browser behavior. Anyway, I fixed the bug I was experiencing with FireFox. It asks for a favicon (http://en.wikipedia.org/wiki/Favicon) and I had to return 404 to avoid freezing the browser. Everything now works great no matter if I use Internet Explorer, FireFox, Chrome, Safari or Opera. :happy:

So I won't be needing jQuery any time soon, but thanks thanks for mentioning it. I hadn't heard about it before and it might come in handy one day...

[Reedbeta]

Firefox hangs if you don't serve a favicon (or 404)? Wow...you may want to report that as a bug to Mozilla, if you haven't already. :)

[Nick]

Firefox hangs if you don't serve a favicon (or 404)? Wow...you may want to report that as a bug to Mozilla, if you haven't already. :)
I'm not sure if this counts as a browser bug. Any sever should simply return 404 on any unsupported HTTP requests, no? My micro-server simply wasn't expecting the favicon request (since that's not part of my HTML code, it's the browser itself making the request). By the way, it doesn't "hang" as in crash. It just doesn't continue executing the code since it's waiting on a response for the favicon request.

If that really means FireFox is broken then so are Safari, Chrome and Opera. :skull: They all request favicon and don't continue. Feel free to report bugs if you care. For me the actual issue is solved for as far as I care.

Ironically, favicon was introduced by Internet Explorer 4, and today Internet Explorer 8 is the only browser I didn't have any issues with. :lol:

[Reedbeta]

I'm not sure if this counts as a browser bug. Any sever should simply return 404 on any unsupported HTTP requests, no?

Yes, it should - but just as a security/robustness principle, it's a bad thing if the browser hangs or crashes due to the server doing something it shouldn't. The client shouldn't need to trust that the server operates properly in order to operate properly itself.

[alphadog]

Actually, the HTTP spec stipulates that "the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server." Basically, the browsers are hanging persistently awaiting an answer. EVERY request must either be answered with a response code.

Presumably, different browsers have different but long timeouts governing this behavior.

[Reedbeta]

Sure. However, the browser shouldn't hang (become unresponsive) if the server is taking a long time to respond, which is what it sounds like Nick experienced. Of course it can continue to wait for the response for as long as it likes and display an error message or some such, but it should continue to process user input while it does so. Else the user gets antsy and kills it in the Task Manager. :)