> most apps can relayout and redraw their window in a tiny fraction of the time that animation takes
Re-rendering to the same compositor target buffer (when you e.g. resize a window), and allocating new textures in (potentially) new formats under control of a new compositor target buffer, are different orders-of-magnitudes of work. Think about how much delay there is from the point you plug in an external display, to the point your windows finish "popping over" onto it and it becomes usable. Allocating a new virtual desktop and moving a window to become fullscreen on it, is doing 90% of that same work.
Why does each virtual desktop have its own compositor and own target buffer? Because each virtual desktop has its own active display mode it's operating under: its own display resolution, its own bitplane format [think RGB vs BGR displays], different memory allocation constraints depending on whether it's currently being mirrored / screen-shared or not, maybe allocated in the VRAM of a different GPU if it's being drawn on a monitor plugged into a discrete GPU's HDMI/DP socket, etc.
This "distinct target buffers with their own compositors" approach is also why you can't span windows across displays on macOS 10.9+. (Before that, macOS used a different approach, that allowed for single virtual desktops that span multiple monitors, but where this would use one big target buffer, formatted to the lowest-common denominator format acceptable to all display targets. So if you plugged in a shitty external display like a 720p projector, and "extended" your desktop to it, then the whole compositor target buffer would get reformatted, and so your internal display's resolution/color depth/refresh rate would decrease.)
> Anyway, I'd trade a bit of pop-in for a faster computer if that was necessary.
My point is that this wouldn't be the trade-off. Instead, you'd switch over to the new fullscreen view, half-rendered — and then it would very likely still take just as long to finish re-rendering and accept input as if there was no animation.
You can actually try this "experience" out for yourself: try having an external display connected; opening Mission Control; and then dragging the focused virtual desktop from your internal display, over to the external display (or vice-versa.) It takes about 3 seconds before all texture assets finish re-allocating in the new compositor target buffer's texture format and re-rendering; and because there's no animation to paper over this case, it just feels unresponsive, like the whole shell has stalled for 3 seconds.
There is absolutely no reason for the common case of maximizing a regular window on the same display to switch texture formats or change resolutions or whatever else. That's silly. The compositor side of maximizing a regular window can and should be implemented in the same way that window resizing normally works, i.e. simply allocating one new screen sized texture to hold the application contents, which can be done in much less than one frame. For special cases like switching resolutions then sure, things can take longer, but that kind of thing is orders of magnitude less frequent than maximizing or switching between regular full screen windows.
If you think that Apple engineers can't optimize the compositor side work that needs to be done to maximize a regular window or switch between regular full screen windows to take less than one frame then you have a very poor opinion of their engineers that I do not share. And if you think it's not worth the effort to optimize a case that typically happens every couple of minutes while people use macOS then I have to disagree in the strongest possible terms.
• Full-screened windows are virtual desktops with special UI treatment.
• Virtual desktops each have their own compositor texture "namespace", so that everything on the virtual desktop can be reformatted to deal with the screen beginning/ending mirroring/sharing, with the desktop being moved to a display that has a different color-space, etc. The copy of textures to new ones owned by the new virtual desktop, allows the compositor to be able to assume that a given desktop exclusively owns all the textures assigned to render on it. (It's the same set of engineering trade-offs as with message-passing IPC. Here the "messages" are textures and the "processes" are virtual desktops.)
• The "optimization" you mentioned exists and I already mentioned it. It was the old behavior. Go into Settings > Desktop & Dock and uncheck "Displays have separate Spaces." Congratulations, now you're using a non-per-virtual-desktop-texture-domained compositor. Enjoy going back to a world where putting your computer to sleep with no display attached, plugging the display in, and then waking it up, makes the kernel panic! But, if you do as a sibling commentor said and turn the animation down to nothing, you will surely notice the performance increase of full-screening windows.
> simply allocating one new screen sized texture to hold the application contents, which can be done in much less than one frame
Yes, this is what the animation that plays does at the beginning of the animation, on the existing virtual desktop — it creates a new, screen-sized texture, and renders the window being "resized to fullscreen" onto it.
Meanwhile, in the background, textures are being message-passed to a new virtual desktop.
> And if you think it's not worth the effort to optimize a case that typically happens every couple of minutes while people use macOS then I have to disagree in the strongest possible terms.
I don't know why you're full-screening windows so often.
> maximizing
Oh, maybe this is your misapprehension? Full-screen ≠ maximize.
Maximizing a window in macOS is what you get by option-clicking the green caption button. macOS calls this "Zoom".
Until Yosemite, this is the one and only thing the "maximize button" on a window did; "full-screened" windows didn't exist as a separate concept. There were just Spaces, with (maybe Zoomed) windows on them.
I — and pretty much every other macOS user I know — regularly uses zoomed (or just resized to be mostly zoomed) windows, but very rarely uses full-screened windows.
For a lot of reasons, full-screen windows on macOS are really inconvenient. They hide the menu bar; they cause some apps to make a ton of their UI elements inaccessible; they make "overlay" apps (e.g. iTerm's "quick access" theme) inaccessible; they make the Dock require a double-bump to access; they make things you open from the Dock open randomly on some other virtual desktop; they make it impossible to drag-and-drop things onto the full-screened window from another window; they make it impossible to grab the window itself with the mouse to move it to another display (instead requiring you to move the virtual desktop the window occupies to the other display); they don't respect application window grouping in Mission Control, so you inevitably "lose track of" the one window you decided to fullscreen; etc. (Also, until more recent macOS versions, full-screened windows couldn't even display modal dialogs or palette windows.) Basically, they take everything that makes macOS more useful than iPadOS and toss it in the trash.
Using windows zoomed rather than full-screened, meanwhile, has none of these problems. (If you want a zoomed window on a separate display, then make a new virtual desktop, move the window there, and then zoom it. I think Magnet has a hotkey for this.)
Re-rendering to the same compositor target buffer (when you e.g. resize a window), and allocating new textures in (potentially) new formats under control of a new compositor target buffer, are different orders-of-magnitudes of work. Think about how much delay there is from the point you plug in an external display, to the point your windows finish "popping over" onto it and it becomes usable. Allocating a new virtual desktop and moving a window to become fullscreen on it, is doing 90% of that same work.
Why does each virtual desktop have its own compositor and own target buffer? Because each virtual desktop has its own active display mode it's operating under: its own display resolution, its own bitplane format [think RGB vs BGR displays], different memory allocation constraints depending on whether it's currently being mirrored / screen-shared or not, maybe allocated in the VRAM of a different GPU if it's being drawn on a monitor plugged into a discrete GPU's HDMI/DP socket, etc.
This "distinct target buffers with their own compositors" approach is also why you can't span windows across displays on macOS 10.9+. (Before that, macOS used a different approach, that allowed for single virtual desktops that span multiple monitors, but where this would use one big target buffer, formatted to the lowest-common denominator format acceptable to all display targets. So if you plugged in a shitty external display like a 720p projector, and "extended" your desktop to it, then the whole compositor target buffer would get reformatted, and so your internal display's resolution/color depth/refresh rate would decrease.)
> Anyway, I'd trade a bit of pop-in for a faster computer if that was necessary.
My point is that this wouldn't be the trade-off. Instead, you'd switch over to the new fullscreen view, half-rendered — and then it would very likely still take just as long to finish re-rendering and accept input as if there was no animation.
You can actually try this "experience" out for yourself: try having an external display connected; opening Mission Control; and then dragging the focused virtual desktop from your internal display, over to the external display (or vice-versa.) It takes about 3 seconds before all texture assets finish re-allocating in the new compositor target buffer's texture format and re-rendering; and because there's no animation to paper over this case, it just feels unresponsive, like the whole shell has stalled for 3 seconds.