20,741
edits
Canvas troubleshooting: Difference between revisions
Jump to navigation
Jump to search
m
→Background: de-quote a bit to keep fellow wiki admins happy ...
m (→Background: de-quote a bit to keep fellow wiki admins happy ...) |
|||
| Line 9: | Line 9: | ||
== Background == | == Background == | ||
{{FGCquote | {{FGCquote | ||
|I'm also interested in any performance issues. For example a canvas is always redrawn if any property changes within the current frame, even if the same value is just written again or changes are too small to be noticeable. Also if a property of a hidden element/group is changed, the canvas is redrawn. Maybe checking if properties have changed enough will gain some speed, but I'm not sure if this will be noticeable at all (only if always the same values are written to the tree...) | |I'm also interested in any performance issues. For example a canvas is always redrawn if any property changes within the current frame, even if the same value is just written again or changes are too small to be noticeable. Also if a property of a hidden element/group is changed, the canvas is redrawn. Maybe checking if properties have changed enough will gain some speed, but I'm not sure if this will be noticeable at all (only if always the same values are written to the tree...) | ||
| Line 46: | Line 27: | ||
}} | }} | ||
Canvas itself is a great piece of technology, but using it to implement complex MFDs is like asking someone to create an object-oriented and multi-threaded application using assembly language: it is possible, but very tedious and requires tons of experience and expertise. This is basically the reason why the most generic Nasal/Canvas code was typically written by people already familiar with FG/SG and OSG internals (i.e. core developers). | |||
The real issue is accessibility - i.e. having things like XML, property tree, Nasal, effects, FDMs and even Canvas is great - but these are really just technology-enablers. | |||
It's very much like driving a car or flying an airplane: you are given an enabling-technology, i.e. an interface to brake, accelerate, climb/descend etc - without having to understand how an engine works, or why an airplane flies. | It's very much like driving a car or flying an airplane: you are given an enabling-technology, i.e. an interface to brake, accelerate, climb/descend etc - without having to understand how an engine works, or why an airplane flies. | ||
To sum it up, FlightGear is not much different from RL here - how many people flying airplanes and driving cars actually understand the underlying systems sufficiently to use them properly, i.e. to make some constraint like fuel efficiency ? | To sum it up, FlightGear is not much different from RL here - how many people flying airplanes and driving cars actually understand the underlying systems sufficiently to use them properly, i.e. to make some constraint like fuel efficiency ? | ||
Whenever someone uses properties, XML, FDMs, Nasal, effects or Canvas - they only need to "understand" a fraction of the complexity involved here, and that comes at a cost obviously. | |||
Let's say, | Let's say, the average contributor understands ~20% of the performance implications their work has (texturing, 3D modeling, scripting, XML, property rules, effects/shaders, FDM, Canvas) - in total, that means that even just per '''feature''' there's a 80% chance that people make fairly inefficient use of the resources available to them through these technology enablers. | ||
So it always is a compromise - accessibility means that we're introducing abstraction layers and giving up control, so that certain stuff can be delegated to user space, which in turn means that we're also accepting the fact that people's work may slow down the whole flying experience until it's no longer flying, but a slide show. | |||
Whenever we've seen dead-slow Nasal/Canvas code it was usually not the problem of Nasal or Canvas, but due to the people who wrote the code in the first place, including my own code by the way. | |||
There's some really -sorry- stupid stuff done in various areas, that makes people think that Nasal and/or Canvas are generally slow. That is not true. Things like the m2000-5 or the extra500 are indeed slow (currently), but not primarily because of Nasal/Canvas, but because of the way Nasal/Canvas code is structured, as well as the resulting scene graph representation that isn't necessarily OSG-friendly. | |||
== Debugging Canvas code == | == Debugging Canvas code == | ||