jsRocket
category: code [glöplog]
Ok, so the way I understand the WebSocket API, the onmessage event-handler gets called for one message at the time. It should be very easy to make sure each command is sent as an individual message over the wire. So as long as that translates to a single onmessage event in JS, we should be able to keep it simple.
OK, I just pushed out a version (same branch as before) that in theory sends each command as a separate message. The greeting-string is also sent as a single message, but that was already the case. So, now I think it should be much easier. Please let me know if there's any issues :)
I'm a bit lost now, tried the hack branch and I'm able to open the connection, and send the greetings, I receive the handshake from Rocket - and when it wants to send pause I get (in Chrome)
After reading http://stackoverflow.com/questions/14596841/websocket-new-frame-byte I changed
And now I'm stuck, as I get
Bummer :\
Here's the test page I currently use:
http://plnkr.co/edit/Q8fIOlKjYd8llXj54PuJ?p=preview
Code:
WebSocket connection to 'ws://localhost:1338/' failed: Received new data frame but previous continuous frame is unfinished.
After reading http://stackoverflow.com/questions/14596841/websocket-new-frame-byte I changed
Code:
clientsocket.h | line ~104 (at the end of "bool send(const char *buffer, size_t length, bool endOfMessage)")
return ClientSocket::send(buffer, length, endOfMessage);
to
return ClientSocket::send(buffer, length + 1, endOfMessage);
And now I'm stuck, as I get
Code:
WebSocket connection to 'ws://localhost:1338/' failed: Received unexpected continuation frame.
Bummer :\
Here's the test page I currently use:
http://plnkr.co/edit/Q8fIOlKjYd8llXj54PuJ?p=preview
Yeah, I'm debugging the problem right now. Thanks for the pointer.
fixed. New branch, cleaned up the code!
Damn you're fast!
Well, I already noticed and started debugging. So I got a head-start on the problem ;)
Pushed up slightly updated code, some cleanups and implemented ping-pong and connection-close.
Pushed *out*.
Bah, took me quite a bit, but I finally was able to send set rows again :)
instead of the former (Websockified)
Guessing that I miss the getTracklength in the new one, or as I understand the code it's not needed anymore O_o
Code:
var pew = new Uint8Array([CMD_GET_TRACK, 0, 0, 0, name.length]).buffer;
_ws.send(pew);
_ws.send(name);
instead of the former (Websockified)
Code:
_ws.send([CMD_GET_TRACK, 0, 0, 0, _syncData.getTrackLength(), 0, 0, 0, (name.length)]);
_ws.send_string(name);
Guessing that I miss the getTracklength in the new one, or as I understand the code it's not needed anymore O_o
Setting tracks not rows, I meant.
I don't quite know why you ever sent that _syncData.getTrackLength()-thing. Here's the corresponding C-code. It should only be CMD_GET_TRACK + 4 bytes of string-length + the string... Perhaps this is why I got the strange behavior?
Oh wait. Did you use the old 0.9-release from sourceforge, perhaps? I did change the protocol at some point, but it's quite a while ago...
Oh wait. Did you use the old 0.9-release from sourceforge, perhaps? I did change the protocol at some point, but it's quite a while ago...
In other news, I started looking at how to structure JSON. So I ended up mocking up some stuff to make sure it's possible to use directly. Will this be usable?
Could be that I really used the old one, weird - but why did I link to your github then - code and beer..
That said, I found this today, and it was the only odd thing I found so far (code rested after the 3ln demo, just looking into it now again).
Really like your mockup, especially the leaner easing functions - this brings some speedgain I guess :)
Other than that, not sure if optimizing the actual transport brings benefits - as that part is completely gone for the demo mode. However it would make it a lot more readable :)
That said, I found this today, and it was the only odd thing I found so far (code rested after the 3ln demo, just looking into it now again).
Really like your mockup, especially the leaner easing functions - this brings some speedgain I guess :)
Other than that, not sure if optimizing the actual transport brings benefits - as that part is completely gone for the demo mode. However it would make it a lot more readable :)
https://github.com/mog/jsRocket/tree/RocketWebsocket
Works again, though I have to clean it up tmr :3
But fucking ace, no Websockify - shit just works - again <3
Works again, though I have to clean it up tmr :3
But fucking ace, no Websockify - shit just works - again <3
I now remember why I used the old Rocket version, as it was the only one I found that has a link to the EXE. The newer one is okay if you have to compile your C/C++ demo anyway - but us webkids usually don't have Visual Studio installed :)
Right. I think I should make a new version rather soon, to prevent people from downloading the old version; I've had similar issues reported recently as well. But I think I'll want to make one before upstreaming WebSocket-support, because it's not unlikely I broke something while doing it ;)
I'm also thinking that I might want to do something about the "officialness" of the repos; people tend to use the GitHub repo as the cannonical source. I intended the sourceforge one to be the official repo, and the github-one to be for "kusma's hacks". But I've started to love GitHub, and I'd like to move to that as the "home". However, GitHub doesn't allow normal uploads of release-files. I guess I could do something hacky like having a binary-builds-repo, though...
I'm also thinking that I might want to do something about the "officialness" of the repos; people tend to use the GitHub repo as the cannonical source. I intended the sourceforge one to be the official repo, and the github-one to be for "kusma's hacks". But I've started to love GitHub, and I'd like to move to that as the "home". However, GitHub doesn't allow normal uploads of release-files. I guess I could do something hacky like having a binary-builds-repo, though...
Just did some measurement on how much the getValue function impacts the render time. Tested it with the sans-rocket minified file.
And the result is quite good, I think - the whole loop takes between nine and 15 ms, one cycle clocking at 0.0009 to 0.00015 ms :)
Code:
function test(){
var row = 10,
its = 10000,
s = Date.now();
for(var i = its; i > 0; i--){
_clearR.getValue(i);
_clearG.getValue(i);
_clearB.getValue(i);
_cameraRotation.getValue(i);
_cameraDistance.getValue(i);
_fov.getValue(i);
}
var e = Date.now();
console.log("total ms:", e - s, "call/ms:", (e-s) / its);
}
And the result is quite good, I think - the whole loop takes between nine and 15 ms, one cycle clocking at 0.0009 to 0.00015 ms :)
As you might have noticed, my getValue-function does binary searching instead of linear-search (as your did). This scales a lot better with big data-sets, but is probably slower on small ones. Just worth mentioning.
Ah okay, will look into it - just tested it with a 6mb XML - (as the 60MB one crashed the browser, bummer). Takes quite a while load, will look into that one now.
For 6000 rows, with 20 tracks it takes:
total ms: 4095 call/ms: 0.4095
When I cycle through all 20 tracks 10'000 times ^^
Testfile maker http://hastebin.com/foyefewoxo.php
For 6000 rows, with 20 tracks it takes:
total ms: 4095 call/ms: 0.4095
When I cycle through all 20 tracks 10'000 times ^^
Testfile maker http://hastebin.com/foyefewoxo.php
Updated the branch https://github.com/mog/jsRocket/commit/1bb4fbf6f4665f7a49879ded92d017b995cf5e63
I think it's clean enough to actually do more optimization now - also used your suggestion/code for the toFloat function :)
I think it's clean enough to actually do more optimization now - also used your suggestion/code for the toFloat function :)
For the binary search, thought a bit about it - as I use a lookuptable to speed that process up - I don't think a huge improvement is possible there.
Unless one has >1000 tracks ^^
However I'm currently trying to improve the actual parsing code - which is darn slow, more precisely the track.add() in syncdeviceplayer.js. Will let you know about my findings :3
So far the biggest fun is really just to open Rocket, and it connects - I still grin when doing that :)
Unless one has >1000 tracks ^^
However I'm currently trying to improve the actual parsing code - which is darn slow, more precisely the track.add() in syncdeviceplayer.js. Will let you know about my findings :3
So far the biggest fun is really just to open Rocket, and it connects - I still grin when doing that :)
Alright, finally got it faster - as always it was the most obvious one, I just neglected it. Sorting after a full track has been filled, instead after each row does improve it a lot, rest does little but enough :)
6MB rocket file took ~180sec before, now ~4sec
(6000 rows, with 20 tracks - every field set)
Good enough, I think.
6MB rocket file took ~180sec before, now ~4sec
(6000 rows, with 20 tracks - every field set)
Good enough, I think.
For the ones who want to see how this was used for a real demo.
Download and start Kusmas compiled Rocket (Websocket branch)
Download and open in Rocket Rocket file for Feliz Navis ASD
Open in your browser 3LN - Feliz Navis ASD
Mind you not all browsers have Websockets implemented yet, stable Chrome and Firefox version should work - if not, let me know :)
Don't link to the above, they won't stay there forever -- If you think your C++ demo should have Rocket (previously downloaded EXE won't work with this! :)
--
[spacebar] play/pause demo
[i] change interpolation
Download and start Kusmas compiled Rocket (Websocket branch)
Download and open in Rocket Rocket file for Feliz Navis ASD
Open in your browser 3LN - Feliz Navis ASD
Mind you not all browsers have Websockets implemented yet, stable Chrome and Firefox version should work - if not, let me know :)
Don't link to the above, they won't stay there forever -- If you think your C++ demo should have Rocket (previously downloaded EXE won't work with this! :)
--
[spacebar] play/pause demo
[i] change interpolation
moc: Seems you failed with the "open in your browser"-link :(