|
From: Thorsten R. <tho...@sc...> - 2017-07-03 17:33:20
|
> My experience is, that Canvas is a real huge framerate eater. > > Space-Shuttle, Extra 500, and the Airbus-Family in developement in the > forum gives me framerates in a single-digit range. > Compared with the good, old-fashioned aircraft we speak about factor of > 5-10 difference in framerates. Speaking for the Shuttle, that has very little to do with canvas as such. There are 11 MDUs on the Shuttle flightdeck, and the way the Shuttle avionics works, they typically display close to a hundred values each, so that's of the order of ~1000 different parameters that need to be simulated, fetched and displayed _per update cycle_ (and yeah, most parameters you see are really simulated and not just unchanging text). If you compare that with showing ~30 different parameters for a simple GA craft, it's naively ~30 times slower for obvious reasons. Try that kind of stunt with a good old-fashioned cockpit, and you'll be lucky to still see single digits... Conversely, displaying the amount of information the analogue gauges of a C-182 hold on a canvas is probably cheaper than doing it by animating 3d mesh. Add to that complexity hundreds of working switches in the Shuttle cockpit (all by necessity different objects slowing down rendering), the ADI ball which is special in that it has to display a true 3-axis rotation not needed for aircraft and a detailed 3d cockpit, and you see the real framerate eaters. Blaming canvas for the sheer complexity of the Shuttle is pointing the finger the wrong direction. Structured in a reasonable way (i.e. minimizing property I/O in update cycles, avoiding canvas pitfalls which trigger high performance needs etc. ) canvas is pretty fast (kind of reminds me of the old 'Nasal is slow' discussions... it's still the same things which are slow, except canvas hides it behind some abstraction - understand property I/O, and it'll run fast) * Thorsten |