Originally posted by riskable
View Post
Announcement
Collapse
No announcement yet.
Open-Source HTML5 Terminal Emulator To Support X11
Collapse
X
-
Originally posted by mikeserv View PostOk, so dirty region updates. As I understand it (in an admittedly limited capacity), this is generally very efficient (and already a standard practice for most remote display protocols) at typical gui window updates and the like but can severely degrade full-fps video transmission, especially as the video display window-size increases and/or fast-moving scenes in the video increase the area per frame that needs updating.
That's probably something I'l investigate *after* the beta is out since the point of the X11 feature isn't to play back video. It's merely an acid test.
Originally posted by mikeserv View PostThis also presents a couple of hurdles that I can imagine:
1) Unless the region capture is performed at a frequency equal to that of the video framerate then it seems video tearing should be expected to occur at least to some extent pretty much consistently for frames not nearly identical to those preceeding them.
Originally posted by mikeserv View Post2) To my knowledge (which, again, is prone to err) nearly any video encoded in a codec seriously updated in the past decade or so is likely to have already incorporated similar dirty-region compression methods. Recompressing in this way must be mostly redundant, yes? It seems it could also exaggerate imperfections in the original compression (e.g.: pixellation artifacts presented onscreen when the decompressed video is played on the server display would register damage events, be captured, converted to JPEG/PNG, transmitted to and then processed by clients' browsers by your protocol, each of which steps could potentially introduce further degradation of quality, I suppose). Have you observed anything like this or am I way off base here?
Originally posted by mikeserv View PostDo you by any chance distinguish between window elements when capturing/drawing the screens? By this I mean, is it possible to assign each window element its own canvas element, or do you do so already? Wikipedia indicates that the XCB connection you mentioned should provide the capability of distinguishing between the disparate windows on the server-side, allowing for simple compression tricks like only accepting damage event updates from X's reportedly active window for instance. If assigned their own canvasses, it could be possible to implement things things like client-side-only window controls which might, for example, take advantage of browser-specific features such as Chrome's canvas to panel/native window flags, enabling a sort of seamless desktop integration.
As far as making applications "seamless": That would require a browser extension. I'll definitely be investigating that once it's working great without an extension.
Originally posted by mikeserv View PostThis is kind of what I was driving at above, and I'm especially curious how what you're doing is more capable of streaming video than what most other protocols can reliably do without incorporating special forwarding extensions, despite your description of the process sounding more or less in line with standard practice. Could it instead be possible to recognize multimedia elements and pass them through directly via WebM?
Even if today's video players don't incorporate a mechanism to determine (from XCB or another mechanism) precisely what they're playing back it doesn't mean I can't ask them to add something like that. Heck, if it means a significant performance boost I'll submit a patch!
Originally posted by mikeserv View PostI apologize if this is all way off the mark, I kinda suck at programming myself so I don't always (read: pretty much never) know what I'm talking about, but I do like to read and do I can sometimes acheive a limited conceptual understanding of the inner-workings of things. I'm mostly just interested in reading some more, is all.
Originally posted by mikeserv View PostAlso, I immediately thought of virtual applications when when I first read this article. Could it be possible to do compositing/rendering client-side with multiple servers running in headless vms? Sort of a reverse to the intended paradigm, maybe, but how cool would it be to switch browser tabs and thereby switch OS's?
Ultimately though, what you're suggesting is indeed very possible. It's just a matter of keeping track of which window belongs where and supporting multiple simultaneous WebSocket connections. I've already got some preliminary zeromq code to keep Gate One servers in sync for when that day comes.
For reference, there's nothing stopping you from having multiple tabs open to multiple virtualized applications right now. Gate One has a mechanism called, "locations". Every terminal/window/whatever belongs to a specific 'location'. So if you wanted to open, say, LibreOffice Calc in a separate tab you'd just add '?location=whateveryouwant' to the end of the Gate One URL. Example:
There's currently no GUI controls for switching locations or moving terminals/windows back and forth between them but the API is already there and it's awesome. From the JavaScript console you can move terminals/windows on-the-fly and even switch your active location on-the-fly. You just call 'GateOne.Net.setLocation("somelocation");' and all your workspaces/terminals/windows/X11 desktops/etc will instantly be swapped out with the ones at that other location.
It's pretty cool (download Gate One and try it!) how well it works. I really need to add a keyboard shortcut that pops-up a little window where you can select and switch locations. It's a really nice way to manage tabs/windows and just plain keep everything organized. It also lets you have as many tabs open as you want, each with their own terminals/apps/desktops/etc.
BTW: The default location is called 'default' if you want to switch back. Also, to send all your apps/terminals from one location to another just call 'GateOne.Visual.relocateWorkspace(workspaceNumber, newLocation)'.
Originally posted by mikeserv View PostAnd last, haven't you done enough? I mean, don't take this the wrong way, but GateOne is already so feature-rich, incorporating so much of what you call "polish," and has become so in such a short-time with no apparent sacrifice in documentation or configurability (to the contrary, I found both a little overwhelming a few months ago when i first tried to set it up)... Don't you do this by yourself, man? How do you find the time to do it all and keep the bugs down? How do you keep it all in your head?
Anyway, best of luck with it all, seriously. Can't wait to try it.
-Mike
Also, I don't keep it "all in my head." Are you kidding me? People report issues all the time with things I haven't worked on in months. When that happens all I can do is refer to my own documentation and extensive code comments that I leave for myself and others for precisely that kind of situation (so I don't forget important facets of the code). There's a reason why every function, method, etc in Gate One has a documentation string: It's so I won't forget, LOL!
Lastly, while Gate One is currently very feature-rich I'm still only getting started! I have a TODO list a mile long. Not only that but the more I work on it the longer that TODO list gets. This is because I'm often working on some code and I think to myself, "Oooh, I just had a great idea!" Then I either write a little TODO comment right there in the code (they're everywhere) or I open up Evernote and add yet another note to my "Ideas" notebook. Over 1000 so far! Not all are related to Gate One but many of them came to me while I was coding it.
Comment
-
Originally posted by droidhacker View PostWhat kind of performance can we expect on something with a weaker CPU, like for example, an MSM8660?
fastethernet,1nic,1wnic,no switch,usb,1usb,usb2.0,serial,802.11bgn,1ant,nondetachableantenna,integrated,32ram,4flash,mips,mips32,24k,ap121,ar9331,ath9k,portable router,usb powered
That thing has a 400MHz Atheros AR7240 CPU, only 32MB of RAM, and Gate One is actually very usable. That device doesn't even have an FPU!
Not only that but I (just now) had four terminals open on that device doing various things (top, tail on logread, etc) and they were all very responsive. Did I mention that this tiny little router is located in Australia (I'm in the US)? Haha. The average ping time for me hovers around 400ms.
Of course, while I was doing all that Gate One was using up about 80% of the device's RAM but what else does it need that RAM for? Certainly not routing tables and firewall rules! Haha.
Interesting fact: After the last session expires Gate One will restart itself into a low memory/resource state that turns off nearly all it's periodic callbacks (background stuff to check various files for changes, mostly). Zero CPU utilization as well. For example, on that TP-LINK device the gateone.py process's memory utilization drops from about 80% to 50% when the last session times out (which I've configured to occur five minutes after the last user disconnects).
Another thing to think about: I haven't tested this in a while but when you run Gate One under pypy (a JIT-compiling, self-optimizing Python interpreter) it runs even faster. Twice as fast last time I tried it.
Comment
Comment