Hello! Does anyone have any experience with native messaging in Chrome? This might sound stupid, but I've got an idea for ultrabullet (of course those who don't play ultra probably won't appreciate this idea). Windows plays sounds with 50ms delay (figured this out after a lot of testing). But researches say that we react faster to auditory stimuli than to visual stimuli. But that advantage of sounds is reversed by the fact that Windows's sound lags. So the idea is to substitute usual Lichess sounds with motherboard sounds (I know you are probably laughing at this moment, but motherboard sounds don't lag at all, almost 0 latency). This would make the reaction much much faster. However, unfortunately I'm really really unfamiliar with native messaging and especially with how to write a host app in Python or c# or anything... Maybe someone would get interested in this idea... Probably not, but who knows :no_mouth:
. +1
Chrome isn't written in Python or C#.
You'd need to modify Chromium (the browser source code) to do this. (Or, for that matter, FireFox.)
Native messaging in Chrome comes secondary to native messaging between the OS (read: kernel drivers) and user-space software stack. (All browsers are user-space, and access generic interfaces to get to hardware-level resources.)
For that matter, even from a novice perspective, you'll have much better support and documentation using Linux to do something like this. (And not Linux run in a VM, but, Linux running on native hardware.)
Yes, I know about some of this stuff. No, I'm not at all interested in anything remotely related to this stuff.
Personally speaking: It would be novel and interesting to do this. On the other hand, it's a dumb idea to have your motherboard beep at you. (The fastest way to do this, with close to zero-latency, would be to listen to a packet interface; see: WireShark; but since it's all HTTPS, you'd have to circumvent your network and/or browser's respective security stacks to accomplish this; so, dumb idea on multiple fronts. Then there's the latency of having your browser first interpret a signal coming over HTTPS, then pushing a signal back down to hardware, whatever that may be.)
Also, sound travels through air slower than light. While the auditory cortex is directly adjoined to your gray matter, whereas the optical nerve travels from front to back of the brain, sounds must be concentrated and focused more than photons; the difference is negligible (especially compared to 50ms latency and magnitude of signal). -- And this is all in the standard literature on the different types of neruons and how they interact with the brain.
You'd need to modify Chromium (the browser source code) to do this. (Or, for that matter, FireFox.)
Native messaging in Chrome comes secondary to native messaging between the OS (read: kernel drivers) and user-space software stack. (All browsers are user-space, and access generic interfaces to get to hardware-level resources.)
For that matter, even from a novice perspective, you'll have much better support and documentation using Linux to do something like this. (And not Linux run in a VM, but, Linux running on native hardware.)
Yes, I know about some of this stuff. No, I'm not at all interested in anything remotely related to this stuff.
Personally speaking: It would be novel and interesting to do this. On the other hand, it's a dumb idea to have your motherboard beep at you. (The fastest way to do this, with close to zero-latency, would be to listen to a packet interface; see: WireShark; but since it's all HTTPS, you'd have to circumvent your network and/or browser's respective security stacks to accomplish this; so, dumb idea on multiple fronts. Then there's the latency of having your browser first interpret a signal coming over HTTPS, then pushing a signal back down to hardware, whatever that may be.)
Also, sound travels through air slower than light. While the auditory cortex is directly adjoined to your gray matter, whereas the optical nerve travels from front to back of the brain, sounds must be concentrated and focused more than photons; the difference is negligible (especially compared to 50ms latency and magnitude of signal). -- And this is all in the standard literature on the different types of neruons and how they interact with the brain.
Do you mean that there will be latency between Chrome and OS with native messaging?
Because I was able to make chrome cause beeps just for testing. I modified an extension-example of native messaging, and was able to trigger mouseboard's beeps when clicking chrome tabs. Chrome sends a message to a host script and there I put a "beep" line.
However, it takes 50ms, which is a lot...
Because I was able to make chrome cause beeps just for testing. I modified an extension-example of native messaging, and was able to trigger mouseboard's beeps when clicking chrome tabs. Chrome sends a message to a host script and there I put a "beep" line.
However, it takes 50ms, which is a lot...
Yeah, I see...
If I trigger motherboard's sounds in Python or AutoHotKey, that takes just a few milliseconds (6ms between clicking a mouse button and a beep). But I won't be surprised if it can't be so fast with Chrome...
But on auditory stimuli: I tested my reaction, and it's actually much faster with sounds than with visual signals. It could be different for other people of course.
If I trigger motherboard's sounds in Python or AutoHotKey, that takes just a few milliseconds (6ms between clicking a mouse button and a beep). But I won't be surprised if it can't be so fast with Chrome...
But on auditory stimuli: I tested my reaction, and it's actually much faster with sounds than with visual signals. It could be different for other people of course.
If you got 50ms from the browser back to the motherboard, then that's likely very close to your absolute latency without compromising your respective network and/or browser security stacks.
Further, on the user-space issue, suggest researching the OSI model and standard software design practices. -- That'll give you a rough idea of what you're working with.
Further, on the user-space issue, suggest researching the OSI model and standard software design practices. -- That'll give you a rough idea of what you're working with.
Thanks for advice; I find it interesting, by the way, to analyse the network with WireShark. Basically I need to trigger a beep every time I receive an opponent's move. Maybe it's possible just by analyzing the amount of data Lichess sends. Basically, it's not necessary to decode that data. It's only necessary to know that it's an opponent's move.
Another idea that could be possibly applied is to observe a page with some web scrapper (I'm bad at this terminology), and trigger a beep every time this element's attribute:
"clock clock_black clock_bottom"
changes to this
"clock clock_black clock_bottom running".
"clock clock_black clock_bottom"
changes to this
"clock clock_black clock_bottom running".
Nope.
Detecting attribute changes in browser-based UI code would introduce additional latency.
You wouldn't need a web-scraper, because it would be a local operation only. (And, even though a local operation, even if you were to "scrape" bytes, filtered on packet, this introduce latency.)
To reduce latency, you have to get as close to the hardware as possible, with as little in-between as possible. Every layer of complexity you attempt to add short of understanding each layer something must pass through to do something else faster negates if not decreases the effect you're looking for.
As for simply reading to/from packet headers (at a low level), your computer will likely beep at you non-stop as your computer polls the server and the server polls your computer through an open socket (non-discriminatory). You have to discriminate between a "push" and a "request" (over whichever open socket). -- And that's where something like WireShark comes in for inspecting packets to make a determination about how to act upon a packet (if you can read enough data to make a discernible decision about how to act or what to do).
Detecting attribute changes in browser-based UI code would introduce additional latency.
You wouldn't need a web-scraper, because it would be a local operation only. (And, even though a local operation, even if you were to "scrape" bytes, filtered on packet, this introduce latency.)
To reduce latency, you have to get as close to the hardware as possible, with as little in-between as possible. Every layer of complexity you attempt to add short of understanding each layer something must pass through to do something else faster negates if not decreases the effect you're looking for.
As for simply reading to/from packet headers (at a low level), your computer will likely beep at you non-stop as your computer polls the server and the server polls your computer through an open socket (non-discriminatory). You have to discriminate between a "push" and a "request" (over whichever open socket). -- And that's where something like WireShark comes in for inspecting packets to make a determination about how to act upon a packet (if you can read enough data to make a discernible decision about how to act or what to do).
Thank you for the advice, it's really helpful. Probably I won't be able to accomplish this myself, but maybe there will be people with necessary knowledge who could get interested in this.
This topic has been archived and can no longer be replied to.