00:00 <gorgonic-> the compiler must be doing something like this

00:00 <gorgonic-> because after adding some more code guff the problem is gone

00:00 <geist> hmm, actually guess mcmodel=kernel doesn't do anything on arm64

00:00 <gorgonic-> but i didn't actually *fix* it

00:00 <geist> yah sounds like you have a heisenbug. okay, another question: is the stack 16 byte aligned?

00:00 <geist> not sure why it'd result in this, but arm64 mandates 16 byte alignment

00:01 <gorgonic-> i think so. I need to provoke it to crash again, just a second

00:01 <gorgonic-> and now it won't do it

00:02 <gorgonic-> extremely disturbing, lol

00:02 <gorgonic-> okay there we go

00:03 <gorgonic-> stack is 16-byte aligned: ffffffc00014bc70

01:43 <geist> hmm, yea dunno with what you have

04:30 <klange> I think all my window spawn animations are now visibly crisper since they're not happening at the same the application is still trying to draw.

04:31 <klange> Nice little change to the compositor, and only one app was missing an initial flip message - ironically, the windowing system test tool!

04:31 <klange> And I've turned off animations for normal dropdown menus, and everything looks great, even under TCG. No weird rendering glitches!

04:38 <klange> I should do that dwell time trick for menus, where there's a little delay before they switch so if you go diagonally from one menu to a submenu and cross a different menu entry it doesn't switch on you...

04:38 <klange> My menu library is such a hack. It's a reimplementation of one I wrote in Python in the beforetimes, and the way it tracks input across the different menu windows is _something_...

04:43 <Izem> klange: did you implement double buffering?

04:45 <klange> Nah, supporting server-side double buffering would be a pretty big change. The plumbing is there for it, I guess, as the resize flow basically does it, but making it work nicely as an exposed functionality for clients will take some work.

04:46 <Izem> I see

04:47 <klange> This was a much smaller change to defer window-open animations until the first 'damage' message (which is called "flip" in all the code, but that's a misnomer given how it actually works...)

04:47 <Izem> what component does the resize flow btw?

04:48 <klange> Resize is a handshake process between the client and the server, it can be initiated by either side.

04:49 <Izem> interesting

04:49 <Izem> that's cool

04:50 <klange> Visual resizing is either directly iniated by the server when a user does alt+middle-mouse, or is initiated by the client-side decorator library via 'yutani_window_resize_start'.

04:51 <klange> The window being resized is transformed by the common affine matrix bilinear scaler that also does rotations and animations, giving a somewhat-silly stretchy look to the "lazy resize".

04:54 <klange> When that stops, the actual handshake process begins with a server-to-client "RESIZE_OFFER" message, which the client can accept, ignore, or respond to with its own REQUEST. When the client gets an OFFER it agrees with and sends an ACCEPT, the server will prepare a new texture buffer.

04:56 <klange> Then the shared client lib takes care of receiving that, swapping around the client-side object, and binding the new texture. Then the client can draw into the new buffer, release the old buffer, and send a "DONE" message, at which point the server will swap to the new buffer, release its side of the old one, and now you've got a bigger or smaller window.