To change the appearance of the cursor, we use the CSS cursor style
and set the url to a data URI scheme. The image data sent via the
cursor pseudo-encoding has to be encoded to a CUR format file before
being used in the data URI.
During Canvas initialization we try and set a simple cursor to see if
the browser has support. Opera is missing support for data URI scheme
in cursor URLs.
Disabled for now until we have a better way of specifying settings
overall (too many settings for control bar now).
Interestingly, the bug depends on compiler behavior. If local
variables are automatically initialized to 0, then this always caused
the program to error out indicating a failure to parse the listen
port. Otherwise, the test was a no-op (except the rare case where the
memory happened to be zero anyways).
Thanks to Eugen Melnikoff for finding this.
The listen port should be opened before daemonizing otherwise if
opening the port fails, the user will get no feedback. The only
complication was that the listen socket needs to not be closed as part
of daemonizing.
Thanks to http://github.com/rickr for finding it.
Add new states 'loaded', 'connect' and 'fatal':
- Loaded state is first page state. Pass WebSockets mode message using
this state.
- Connect indicates that the user has issued a "connect" but we
haven't gotten an WebSockets onopen yet.
- Fatal is a condition that indicates inability to continue on: right
now, lack of WebSockets/Flash or non-working canvas.
Move much of the actual state transition code into updateState.
Handle 'password' state better in default_controls.js; instead of
disconnecting, prompt for password to send.
Add comments to updateState indicating possible states.
Interestingly it turns out that using the native base64 routines does
not improve performance. Likely because the actual time is in
marshalling/unmarshalling between strings and arrays (and associated
garbage collection overhead) which has to be done either way.
Util.Debug, Util.Info, Util.Warn, Util.Error routines instead of
direct calls to console.*. Add "logging=XXX" query variable that sets
the logging level (default is "warn").
Logging values:
debug: code debug logging (many calls in performance path are also
commented for performance reasons).
info: informative messages including timing information.
warn: significant events
error: something has gone wrong
The problem is, you can't set WebSocket.__swfLocation before you load
web_socket.js (because it creates the WebSocket global), but you also
can't reliably set WebSocket.__swfLocation after because if you are
doing dynamic script file includes then the onload (i.e.
WebSocket.__initialize) may fire before you have a chance to set
Websocket.__swfLocation.
Add message/state pollling in web-socket-js. Since Opera tends to drop
message events, we can dramatically increase performance by polling
every now for message event data.
Also, add more direct calls to update readyState so that it's not
missed when Opera drops events.
When using web-socket-js, the onopen event may happen inline so the
caller may not have time to set onopen before the event fires. In this
case set a short timeout and try again. In particular this affects
Opera most of the time.
Also, to get around Opera event droppings, always read the readyState
directly instead of relying on the local readyState variable to be
correct (which it isn't if stateChange event were dropped).
All browsers with Canvas imageData are faster with JS ops instead of
canvas ops. This gives significant performance improvement in Opera.
Except for missing web-socet-js message notifications, Opera 10.60 is
now faster than firefox 3.5.
Instead of relying on FABridge AS -> JS event delivery, we just use
the events to notify JS of pending data. The message handler then
calls the AS readSocketData routine which sends back an array of
the pending WebSocket frames.
There is still a minor bug somewhere that happens after the first
connect where the web-socket-js throws an "INVALID_STATE_ERR: Web
Socket connection has not been established". But, Opera is now usable
and we should be able to drop the packet sequence numbering and
re-ordering code.
Another minor issue to better support Opera is to move JS script
includes to the <head> of the page instead of after the body.
Pull in LGPL md5.c and md5.h files (written by Ulrich Drepper).
Now both python and C version of the proxy support both protocol 75
and protocol 76 (hybi 00).
Reorganize websocket.py slightly to match websocket.c.
Interesting. Enough has changed in the Canvas tile operations, that
Canvas.prefer_js=true is better for firefox/gecko too. Approximately
2X improvement in firefox for large hextile renders.
Looks like disabling web-socket-js debug messages by default that we
get a minor speedup.
Python proxy should support both 75 and 76 (00) modes. Also, update ws
test to more reliably hit the WebSockets ordering/drop issue.