Feedback Technical Grievances

Depends what you're using. An old, shitty burner iPad with 2GB RAM (and an anaemic A10 CPU) has way more trouble with KF than it should, and a lot of that is probably due to rust chat bogging it down.
 
  • Agree
Reactions: Pee Cola
Opening the .net homepage still opens chat and signs me into it automatically, and there doesn't seem to be any button to disconnect/opt out.

"So everyone had performance issues with chat but just didn't notice it?" I noticed when my entire computer started freezing, I opened task manager, killed my browser once I was able to, and it fell from using 16GBof RAM thanks to a memory leak or something similar in chat to ~1.5GB.
 
  • Dumb
Reactions: Betonhaus
Has the character limit been reduced for an entire post to become unquotable? For instance, this post has 2458 characters and is over the limit. I thought the limit was like 5K or 10K characters.

I know the workaround of highlighting specific text and using the popup to quote/reply, I was just curious if something had changed.
 
My 'political sperging' button is not working. I need it urgently for the Palestine/Israel thread!
 
  • Dumb
Reactions: Betonhaus
It has always been 2000.
I actually second it having been larger before. What's up with that anyway, a measure to prevent lazy phoneposters or just lazy posters in general to skip out on editing down massive quote blocks, or just something built into Xenforo?
 
Lately (I'd say for the past week) I have an absolutely craptastic time posting on kiwifarms.net. I write my post, click post, this little busy thingy at the top appears but just eventually disappears and the post doesn't get posted. Takes several attempts, sometimes it goes through, sometimes it just doesn't. This is on Firefox via mullvad. On Tor no issues. (I tried Ctrl+F5'ing)

To be fair, the problem might be mullvad. It's been kinda crappy lately.
 
Lately (I'd say for the past week) I have an absolutely craptastic time posting on kiwifarms.net.
Try .st ... I find .net tends to be a bit janky at times, but .st only has problems whenever KF is subject to full dilation.
 
So everyone had performance issues with chat but just didn't notice it?
With many tabs open I found that the chat could have RAM overhead exceeding 80GB. It really was that slow. The same number of tabs on my system now has minimal impact. It's important to remember that Javascript can run like an absolute pig if it's not carefully optimized and many web stacks are written with no concern for efficiency. Facebook is much worse, having it open on just a couple tabs can slow an older laptop.
 
  • Like
Reactions: Vecr
Dumb question, but is there some sort of way for all open tabs to share the same chat script and websocket? So instead of every page deploying it's own chat code and making it's own WebSocket connection to the server, they somehow communicate with each other and display the exact same instance of code? I don't know if there is a way for the tabs to tell the browser to keep an independent instance active for as long as any tab with chat is open, or if the tabs would have to assign one tab to be running the code - with keepalive code detecting if that tab was closed or suspended. Maybe look into PWA features?
 
Last edited:
Dumb question, but is there some sort of way for all open tabs to share the same chat script and websocket? So instead of every page deploying it's own chat code and making it's own WebSocket connection to the server, they somehow communicate with each other and display the exact same instance of code? I don't know if there is a way for the tabs to tell the browser to keep an independent instance active for as long as any tab with chat is open, or if the tabs would have to assign one tab to be running the code - with keepalive code detecting if that tab was closed or suspended. Maybe making chat into a PWA app or implementing an open source engine like Rocket Chat?
I think this would be possible with a shared web worker thread, although getting an existing chat script to use a shared web worker thread for its communications would be the trick.

You could probably override the default WebSocket object with a custom class that uses a shared web worker for all of the underlying communications (and the shared web worker opens the real WebSocket and merely passes data to/from all pages that need it).
 
Back