3 ms·

Once upon a time someone showed me an amazing demo of streaming over a million rows a second into a table in HTML. I told him that was cool. I asked him where

by geocar 2y ago

Once upon a time someone showed me an amazing demo of streaming over a million rows a second into a table in HTML. I told him that was cool. I asked him where the screen was that could draw a million rows, and after my confusion was sorted it turned out there wasn't one and I probably should have guessed as much. The screen was a regular screen and could only display 60 or so rows legibly and that is life, so the other million (minus 60) were streaming "invisibly" into the bitbucket that was maybe the user will scroll this into view within the next second before the data is going to change again, but almost certainly won't, because well, a million a second is actually quite a lot. So I thought for a minute and asked him why he didn't just send 60 and he quickly said well that wouldn't be as fast. And I still think about that.

Aardwolf 2y ago
I don't know man, I really feel the difference when natively scrolling in a webpage that has everything rendered already, vs things that load and change as you scroll. I have a free-flying scrollwheel. Native feels much better, faster and responsive.
- geocar 2y ago
  Do you play video games? They've got a good trick: Send the velocity of the scrollwheel instead of what the client thinks its y-position is. Fast mice can give this to you at 100hz, but most USB mice are delivering data much slower. Remember the server knows what time it is and what the RTT is so it can compute the correct row number and send frames at frequency. You can also send a little bit more than 60 lines to help hide the latency at the start of scroll, and if you need more you're probably scrolling so fast you wouldn't notice some deliberate motion blur. I guarantee if the server can send a million rows a second, it can definitely receive one sample and send 100 rows 100 times a second no problem, and you know what? You can also scale that down under less-than-ideal network conditions trivially helping those users who would absolutely prefer to get the result on the screen faster once they've stopped scrolling than to be waiting for TCP buffers to uncork. Like I said, I still think about this...

by geocar 2y ago

Aardwolf 2y ago

I don't know man, I really feel the difference when natively scrolling in a webpage that has everything rendered already, vs things that load and change as you scroll. I have a free-flying scrollwheel. Native feels much better, faster and responsive.

geocar 2y ago
Do you play video games? They've got a good trick: Send the velocity of the scrollwheel instead of what the client thinks its y-position is. Fast mice can give this to you at 100hz, but most USB mice are delivering data much slower. Remember the server knows what time it is and what the RTT is so it can compute the correct row number and send frames at frequency. You can also send a little bit more than 60 lines to help hide the latency at the start of scroll, and if you need more you're probably scrolling so fast you wouldn't notice some deliberate motion blur. I guarantee if the server can send a million rows a second, it can definitely receive one sample and send 100 rows 100 times a second no problem, and you know what? You can also scale that down under less-than-ideal network conditions trivially helping those users who would absolutely prefer to get the result on the screen faster once they've stopped scrolling than to be waiting for TCP buffers to uncork. Like I said, I still think about this...