Yes, it does, mostly. It doesn’t actually get returned to the system–most allocated memory doesn’t–but that memory can still be subsequently reused by Panda operations, to a point limited by fragmentation and related problems. But I think the fundamental problem with loading egg files in the runtime client is that once the graphics context has been created, there is much memory already allocated for that purpose, and then the egg loader adds memory on top of that–and it becomes easy to exceed the paltry 2GB limit that Win32 provides.
This affects only the compile-time packing of structures, which we are already handling correctly with the EIGEN_ALIGN16 and other related definitions. But these kinds of alignment rules all assume that the the structures start on a 16-byte aligned block of memory, which might not be true for the memory returned by malloc(). (Actually, I’ve seen differing reports on whether this is true or not for Win32 malloc(), and I just thought it best to assume there exist cases for which it’s not true without actually testing it. For instance, maybe it’s true for Win7, but not on WinXP; and who wants to go around and test all of the existing Windows versions?)
Yes, but again, this refers only to the compiler packing, and it fundamentally assumes that the runtime memory is already aligned (which is what Panda will be responsible for guaranteeing one way or another, especially if you use PANDA_MALLOC() / PANDA_FREE() to manage your memory allocations).
David