Nem a két képkocka közötti idő: egy képkocka mennyi idő alatt készül el. Nem csak itt, hanem az összes milliszekundumos értéknél.
Azok a csíkok nem a CPU magok: a nevük is mutatja, hogy szálak (Thread). Köze nincs a CPU-hoz. A programkódban vannak létrehozva ezek a szálak, a programozó hozza létre őket. Kivéve a MainThread-et, mert az a Windows Process kezelője kreálja, amikor betöltés után elindítja az alkalmazást. Kivétel nélkül minden windows alkalmazásnak van MainThread-je. Ezen, és csakis ezen történik az alkalmazás eseménykezelése, tehát ha kattintasz az egérrel, akkor ennek a szálnak a ProcessMessage-ében kapja meg a WM_MouseDown, elengedéskor pedig a WM_MouseUp eseményt. Ugyanígy billentyűnyomásnál, meg mindennél, de a rendszer is így utasítja az alkalmazást, hogy pölö rajzoljon ki ezt meg azt. Ezért nem szabad ezt a szálat leterhelni, mert az események beolvasása "idle" időben történik. Ha tehát a CPU ebben a szálban valami teljesen máson ketyeg, addig nem lesz eseménykezelés míg be nem fejezi (erre való a homokozás). Ezért törekszünk arra, hogy ebben a szálban csak elkapjuk az eseményt, kikódoljuk, hogy mit akar, és elküldjük egy már működő szálnak, vagy gyorsan létrehozunk egyet. De ha pl. az a feladat, hogy rajzoljunk valamit a képernyőre, azt nem maga az alkalmazás teszi, hanem inkább a windows, mert a driverek nem az alkalmazáshoz kapcsolódnak, hanem a windows-hoz. Ezért ezek a driverek (VideoDriver) nem osztott erőforrások, egyszerre nem lehet több helyről basztatni őket. Illetve lehetne, de elég siralmas lenne a végeredmény. Ezért hiába hozunk létre bármennyi szálat, abból nem rajzolhatunk pl. a D3D driverek felé, hanem össze kell szinkronizálni a MainThread-el, és annak átadni a már elkészített rajzot, vagy annak darabkáját (pl. sprite). És majd a MainThread fogja esemény formájában (SendMessage vagy PostMessage) a windows felé továbbítani. A windowsban minden driver, alkalmazás csakis ilyen formában "társaloghat", és alapvetően ezért van szükség minden processnél a MainThread-re. És így már érthető az is, hogy miért kell a MainThread-nek szabad időt biztosítani.
A MainThread alatt a többi csík, az alkalmazásban a videómegjelenítésben legfontosabb szálak állapotát jeleníti meg. A RdrThread és a hozzá tartozó idő azt mutatja meg, hogy a renderelő szálnak mennyi idő kellett az utolsó képkocka előállításához. Alatta a CPU coherencia ugyancsak a képkockára vonatkozó infóval. Az alatt a GPU-hoz tartozó szálak ugyanezen infóit tartalmazza. És így tovább.
Az MSFS egy ritkán jól optimalizált alkalmazás. Több mint 20 éve oktatok programozókat arra, hogyan lehet jól felosztott alkalmazásokat írni. Sajnos elmondható, hogy minél több szálat használunk, annál drágább lesz az előállítás. És ez piacpolitikai probléma, nagyon nagy küzdelem a cégeket rávenni, hogy ne egyszálas (MainThread) alkalmazásokat írjanak (ti is tapasztalhatjátok, hogy milyen sok homokozással találkozhattok). Szóval rengeteg alkalmazást láttam már. Ez a cucc a legjobbak közül való. Annyira, hogy amikor találkoztam vele meg is lepődtem. Nem számítottam rá, hogy elsőre megugorják ezt a szintet. Nem egyszerű többszálas alkalmazásokat írni, a sok szál "egyben tartása" pedig még bonyolultabb. A programtervezőnek, a szervezőnek és a programozónak is elég felkészültnek kell lennie. A D3D pedig sokkal keményebbé teszi a feladatot. Pl. többszálas alkalmazás szervert némi képzés után bárki írhat, de egy 3d grafikus alkalmazásba a legtöbb programozónak beletörik a bicskája.
Sanya bácsinak egyértelmű gép problémája van, aki ismeri a gépének konfigját, akkor a linkelt képről azonnal be lehet gyűjteni néhány hibát, hogy miért is. És már rutinból tudom, hogy ha ezen az egy képernyő darabkán így el vannak piszkálva a dolgok, akkor szinte mindenütt lehet csontvázakat találni. Egyáltalán nem az MSFS-el van a baj. Az MSFS annyira rugalmas, hogy azon a régi gépen is lehetne erős közepes (szinte már jó) eredményt elérni. Ennél sokkal gyengébb gépeknél megoldottam már. Elismerem, hogy nem ideális a gép az MSFS-hez, de használható lehet tenni.