actually, it wouldn't make that big of a performance hit, because that's not where OrbiterGen spends most of its time.
OrbiterGen has two discrete passes:
In pass 1, it builds a rendering tree from the information in the database, joining together all the information between the various tables, to provide what is essentially a scene graph.
The goal in pass 1, is to create tree branches with as few nodes as possible, because in a screen if nothing changes, a single graphic for the top level designobj is rendered. Otherwise, each time there is a potential child designobj within a designobj that changes, OrbiterGen must render each potential change as a separate graphic, thereby increasing orbiter generation time. This is why Pluto decided later in the game to not use discrete state changes in the Basic skin, and opted to dynamically draw rectangles for selected states, etc. They wanted to cut down on Orbitergen's rendering time.
Now this also implies, that if MNG animations are used, that EACH AND EVERY FRAME for a given region must be rendered separately! (this is actually what happens)
In Pass 2, the rendering trees are used, to direct an image compositor to combine all the requisite images for a given area into a flattened png, and scale them down to the target size dictated by an orbiter's PK_Size.
I hope this explanation makes things a bit more clear.
-Thom
