"Ola Fosheim Gr?stad" <[email protected]>"> On Tuesday, 4 February 2014 at 00:49:04 UTC, Adam Wilson wrote: >> Ahem. Wrong. See: WinForms, WPF, Silverlight. All extremely successful GUI >> toolkits that are not known for GC related >> problems. I've been working with WPF since 2005, I can say the biggest >> performance problem with it by far is the >> naive rendering of rounded corners, the GC has NEVER caused a hitch. > > According to Wikipedia: > > ?While the majority of WPF is in managed code, the composition engine which > renders the WPF applications is a native > component. It is named Media Integration Layer (MIL) and resides in > milcore.dll. It interfaces directly with DirectX > and provides basic support for 2D and 3D surfaces, timer-controlled > manipulation of contents of a surface with a view > to exposing animation constructs at a higher level, and compositing the > individual elements of a WPF application into > a final 3D "scene" that represents the UI of the application and renders it > to the screen.? > > So, Microsoft does not think that GC is suitable for real time interactive > graphics. And they are right.
As long as other code is in managed code, there is GC running at background, no matter your code write in whatever high performance language, it will be affect by GC anyway. so that "So, Microsoft does not think that GC is suitable for real time > interactive graphics. And they are right." is only your opinion. you don't know the real reason behind MS's decision. some resource need release ASAP, so you can't rely on GC. or maybe bacause of overhead when call low API in managed code.
