#DRM #WEB worries? Here's another free way. 5711 bytes to stdout from awk or lisp or clisp (doesn't matter) over the wire as an #altair #gui #cloud app with dependencies of C #sockets #XCB and nothing else not even fonts on the thin client end, 160k footprint. This was made for apps but no reason the complicated html/css/svg/js stuff couldn't be pushed back to a server unlocking the much smaller over the wire and tinier footprint of the ui. code free out on bitbucket timcdoc antibrowser

This is why browsers must go away, here is #firefox when I click on a link in mastodon "Isolated Web Co" 1.5g-1.7g WTAF?! and it takes 5 min to load. I just want to watch the youtube.I stopped using chrome because of the upcoming DRM shti but might have to switch back just 2 get something working. Chrome has a 300M footprint and that's way better than 2G! For Reference my thin client antibrowser starts out with 160K and bloats to 8M because the shared memory #XCB needed to get >1 Frame/sec

@bunnyhero ya mine too! I really hope there's some #xcb way to do this out there somewhere. I can work around this by only allowing one thin client that takes over the entire screen and forks instances for each cloud connect to an app server that means the 8M penalty is one time and I can again run 200+ clients without stressing the machine much.

@bunnyhero I have a question, (you or anyone really) My thin client antibrowser for cloud apps used to be 252k and I've reduced it to 160k but as soon as I have to allocate an #xcb shared buffer it bloats to 8M (I need to do this to get from 2 frames a second to reasonable frames/sec) I REALLY REALLY miss scribbling into the frame buffer directly and not dealing with copycopycopy shtforbrains software #GetOffaMyLawn 🙂 (Still better than 300M chrome, but...)

Asking another way. #xcb 20 frames a second, no need for an 8meg local buffer, go! Be aware this would drop my thin client #antibrowser from 8.2Mbytes to 200Kbytes. Ideally I'd like a /dev/fb without sht on top like we had in late 90s, but I know that won't happen again

I forgot how fun it is to write simple compilers, especially if you completely skip the optimization stage and only do very basic parsing.

The project in question is generating #XCB bindings from the XML protocol description files and turning them into #Scheme code. Hand wrote enough bindings first for a X11 handshake, now trying to automatically emit them.

What u will c is 21 languages #ada #awk #bash #basic #C #clisp #C++ #COBOL #Forth #FORTRAN #go #java #lisp (mine) #lua #Pascal #Perl #Python #R #Rust #Ruby #SED calc app srvs <=>stdinout. C,C++<=> sockets, 23 thin clients with NO dependencies besides C #xcb #sockets. 21 thin server apps in C that translate stdin/out to/from sockets in a language agnostic way. What you WON'T see are any #browsers (1000x the footprint of my thin clients) or fonts, https://www.youtube.com/watch?v=Esv6xHwZRYc

Where are my #xcb peeps?! I have a bug, I KNOW it is fixable. The hack is to always run and launch app wndows so there is a window underneath or even just drag another window to touch, then 100% of the window turns from back to what it is supposed to be. What event should/shouldn't I be using?

I don't know who needs to hear this, to hack around #xcb s #bug of not drawing anything but black after image copy with flushes EVERY FKING PLACE, simply maximize a random window before launching #YouReFKingWelcome #ThereIfixedIt 💩 to make the bug happen run the window on a space that has no window in the background

Welp enough time wasting! gotta rip out #shm from #xcb and judging by the sample app I found, I should go from 2 frames/sec max to possibly hundreds at least for small area changes

hmm might have to start pumping in 0's to every damned option besides width and height to get #xcb to honor width and height SONOFA!! No no, I don't want borders, no no, I don't want random numbers for borders? Is that what's going on here? At least it works. #FragileTechSaysWhut

I desperately need to talk to a #xcb expert(or not) about how to shove perfectly good working picture resize under xcb right the **** through #wayland I've gone through a lot of trouble to remove font and graphics dependencies so I don't need X11, why does wayland F with xcb calls? It's like they aren't fully implemented? If anyone can change a window size using xcb the same way in wayland as NOT wayland, please! LMK TIA

NO more #x11 #fonts just using #XCB C in the thin client code (No browsers either! THe footprint of this is 272KiB and it is only slightly slower than x11's 7MiB footprint version. Oh also X11 bugs show fonts bigger than 15 hit or miss mostly white on white. Here is the functions used to generate and write the fonts directly on what I would have liked to have been /dev/fb0I guess xcb is as close as I'm going to get to ripping out all the cruff layers of useless bloat?

Font sizes shown are 1..40 can go up to 188 #Functional #Fonts zero dependency on traditional fonts, #xcb and 6k text functions, no storage, printed/generated in place

My small #xcb merge request just got merged! Some X11 apps should hopefully be a bit less crashy. #opensource

https://gitlab.freedesktop.org/xorg/lib/libxcb/merge_requests/5