20,741
edits
Canvas troubleshooting: Difference between revisions
Jump to navigation
Jump to search
m
→Background
m (→Background) |
|||
| Line 4: | Line 4: | ||
== Background == | == Background == | ||
{{FGCquote | |||
|Whenever I'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 :D <br/> | |||
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, but not primarily because of Nasal/Canvas | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=208857#p208857 | |||
|title=<nowiki>Re: The Garmin 196</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Sat May 10</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|if we don't look at improving performance right now, we cannot realistically replace the map dialog or the navdisplay | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193857#p193857 | |||
|title=<nowiki>Re: How to display Airport Chart?</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Nov 11</nowiki> | |||
}} | |||
}} | |||
{{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...) | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193941#p193941 | |||
|title=<nowiki>Re: How to display Airport Chart?</nowiki> | |||
|author=<nowiki>TheTom</nowiki> | |||
|date=<nowiki>Tue Nov 12</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|I'm currently working on this one (lazy updates/rendering). I have some working code, but it's very hackish. So if anyone has experiences in render-to-texture on demand in OSG any hint is appreciated | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=166990#p166990 | |||
|title=<nowiki>Re: </nowiki> | |||
|author=<nowiki>TheTom</nowiki> | |||
|date=<nowiki>Fri Sep 21</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|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. | |||
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 ? | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209634#p209634 | |||
|title=<nowiki>Re: Dev and test environment</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Thu May 15</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|whenever someone uses properties, XML, FDMs, Nasal, effects or Canvas - they only need to "understand" a fraction of the comlexity involved here, and that comes at a cost obviously. | |||
Let's say, most contributors understand ~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. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209634#p209634 | |||
|title=<nowiki>Re: Dev and test environment</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Thu May 15</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|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. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=209634#p209634 | |||
|title=<nowiki>Re: Dev and test environment</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Thu May 15</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|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). | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=231068#p231068 | |||
|title=<nowiki>Re: Project Farmin [Garmin Flightdeck Frame work]</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Feb 02</nowiki> | |||
}} | |||
}} | |||
== Debugging Canvas code == | == Debugging Canvas code == | ||