The code creates a new buffer for each frame and then pushes that into the gif. There is no freeing of memory or any kind of ring buffer being setup. So yes, it keeps eating memory.
One way to improve my Instant Background Uploader app [1] and make it actually instant would be by doing just that. Generate the image URL right away and start streaming it while the upload continues.
Instead of waiting for upload to finish before giving you a URL.
But you'd need control over the image hosting backend cuz ImageShack won't let you do it.
I am also currently working on a web-based remote desktop app as a side project. I am using socket.io (python port) and pngs, using transparency to only update the part of the image that changed between frames.
However, I also thought about using long-loading animated gifs, because:
1. Run-length encoding seems to be ideal for screenshots.
2. You can use transparency to only update pixels that changed between frames without need for an alpha layer.
3. Palette-based does not seem to be a big issue for screenshots, which typically have few colors.
4. You use an additional frames to update colors that are off [1]. That way you get the best of both worlds: low latency and high quality images.
Do you have any issues using gifs? Memory usage, closing connections, etc...?
GIF doesn't have RLE. It only has dictionary built from "previous pattern + 1 new pixel", so even transparent areas are wasteful (1+2+3+4+5+6px etc in optimal case and you have to restart when 4K-entry dictionary fills up).
Is this supposed to install on Windows? I get a whole bunch of errors when I run "npm install -g vnc-over-gif", most of which seem to be related to node-gif.
Edit: Apparently they're related to unistd.h, which doesn't exist on Windows platforms. Too bad.
I might hack a bit on JS-only gif encoder this weekend but at the moment yes, you need to have proper development environment to compile under windows. unistd.h dependency might be an easy fix though
Interesting that npm is being used to deploy a regular old CLI application that has essentially nothing to do with javascript development. Are we seeing the future of package management with these distribution-agnostic tools?
No, you're just seeing javascript come into its own as a general purpose language community. The surprising part isn't that it's being shipped in npm, it's more that people like programming these sorts of tools in javascript.
This sort of thing is common in Ruby and Python-land. And infinitely better than the `curl foo.io/trolol.sh | sh` we've seen emerge in the last couple of years.
Very interesting. I have a tool that I use for supporting our iOS apps that streams screenshots of the users session to a browser window. Right now I just have that browser window refreshing every 2 - 3 seconds but this could be a much more interesting way to stream those screenshots. Non-technical users + no screen sharing on iOS is absolutely awful for supporting SaaS applications.
This nicely solves a problem I've been asked about: how to share a screen securely (read-only). VNC protocol and implementations are too complex/sloppy so I don't trust them. An endless GIF, on the other hand...
It is an afternoon read. Most desktop environments in Linux implement their own VNC server just because it isn't that complex and you can implement a subset of the protocol for a server anyway.
I imagine if there was a protocol flaw revealed (or even in the many implementations like libvncserver) it would be patched overnight. All of them support viewer-only mode. I like krfb, because by default it only uses access passes rather than a global password, so unless you give someone credentials of an access ticket nobody can login.
I bet an exploitation in the way gifs download and how http resolves file transfers in the dozens of implementations of both is much more likely to have an exploitable man in the middle or other mechanism to eavesdrop, if not take remote control.
Yes, I was thinking about server-side image maps and link with target in invisible frame. Mouse movements are harder (if possible) to send without client side javascript
[+] [-] tokenizerrr|13 years ago|reply
[+] [-] MarkHarmon|13 years ago|reply
[+] [-] sidorares|13 years ago|reply
[+] [-] arturadib|13 years ago|reply
[+] [-] jstanley|13 years ago|reply
This is perfect.
[+] [-] caissy|13 years ago|reply
[+] [-] shurcooL|13 years ago|reply
Instead of waiting for upload to finish before giving you a URL.
But you'd need control over the image hosting backend cuz ImageShack won't let you do it.
[1] https://github.com/shurcooL/InstantBackgroundUploader_OS-X https://github.com/shurcooL/InstantBackgroundUploader_Window...
[+] [-] endergen|13 years ago|reply
[+] [-] matrix9|13 years ago|reply
[+] [-] ma2rten|13 years ago|reply
However, I also thought about using long-loading animated gifs, because:
1. Run-length encoding seems to be ideal for screenshots.
2. You can use transparency to only update pixels that changed between frames without need for an alpha layer.
3. Palette-based does not seem to be a big issue for screenshots, which typically have few colors.
4. You use an additional frames to update colors that are off [1]. That way you get the best of both worlds: low latency and high quality images.
Do you have any issues using gifs? Memory usage, closing connections, etc...?
[1] http://phil.ipal.org/tc.html#
[+] [-] pornel|13 years ago|reply
[+] [-] Aqwis|13 years ago|reply
Edit: Apparently they're related to unistd.h, which doesn't exist on Windows platforms. Too bad.
[+] [-] sidorares|13 years ago|reply
[+] [-] shawnz|13 years ago|reply
[+] [-] phillmv|13 years ago|reply
This sort of thing is common in Ruby and Python-land. And infinitely better than the `curl foo.io/trolol.sh | sh` we've seen emerge in the last couple of years.
[+] [-] staunch|13 years ago|reply
[+] [-] tokenizerrr|13 years ago|reply
[+] [-] jonpaul|13 years ago|reply
[+] [-] shurcooL|13 years ago|reply
[+] [-] zachc|13 years ago|reply
More info if you're interested: http://zachcimafonte.com/GIF-Window-Server
[+] [-] ma2rten|13 years ago|reply
[+] [-] jabz|13 years ago|reply
[+] [-] arde|13 years ago|reply
[+] [-] zanny|13 years ago|reply
The protocol is 50 pages long with pretty reasonable margins and it even has pictures: http://www.realvnc.com/docs/rfbproto.pdf
It is an afternoon read. Most desktop environments in Linux implement their own VNC server just because it isn't that complex and you can implement a subset of the protocol for a server anyway.
I imagine if there was a protocol flaw revealed (or even in the many implementations like libvncserver) it would be patched overnight. All of them support viewer-only mode. I like krfb, because by default it only uses access passes rather than a global password, so unless you give someone credentials of an access ticket nobody can login.
I bet an exploitation in the way gifs download and how http resolves file transfers in the dozens of implementations of both is much more likely to have an exploitable man in the middle or other mechanism to eavesdrop, if not take remote control.
[+] [-] Falling3|13 years ago|reply
[+] [-] mzs|13 years ago|reply
[+] [-] csears|13 years ago|reply
Made me chuckle, but probably quite accurate.
[+] [-] anonymfus|13 years ago|reply
[+] [-] sidorares|13 years ago|reply
[+] [-] aespinoza|13 years ago|reply
[+] [-] imperialdrive|13 years ago|reply
[+] [-] JeremyMorgan|13 years ago|reply
[+] [-] MacsHeadroom|13 years ago|reply
[+] [-] ritonlajoie|13 years ago|reply