Talk:Switching default texture format to DDS: Difference between revisions

Jump to navigation Jump to search

Talk:Switching default texture format to DDS (view source)

Revision as of 00:43, 7 September 2014

2,829 bytes added ,  7 September 2014
m
→‎Proposal for a change input format "on the fly" in the texture format: Canvas comments
Line 66: Line 66:
:::But it is still an assumption and nothing I could proven yet.  
:::But it is still an assumption and nothing I could proven yet.  
:::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 20:24, 6 September 2014 (UTC)   
:::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 20:24, 6 September 2014 (UTC)   
:: @HHS: Like I said previously: processing/parsing SVG files is indeed relatively slow because the parser is implemented in Nasal, but the only thing svg.nas is doing is looking for supported elements and converting them into so called CanvasElements, mainly osgText and shivaVG paths via CanvasText/CanvasPath.
:: In other words, all the "heavy" stuff is done directly when parsing the file - people using complex SVG files will see that the loading overhead does show up, not just because of the Nasal-based parser, but also due to the fact that possibly a ton of drawing primitives are converted into properties and put into the main property tree.
:: That's basically where things can be (and sometimes ARE) pretty slow. This part isn't currently optimized very much. However, all that being said, once the Canvas tree is set up and resides in the FlightGear property tree, rendering complexity is mainly a function of the number of modifications, and the result can be dealt with like a conventional raster image (e.g. PNG).
:: We're using the canvas:/// syntax to even reference complex SVGs as raster images and set up a simple NxN grid of symbols that is to be used as a cache. Thus, regarding your concern, the question is mainly if the SVG file is permanently animated or if it's rather static ?
:: The "static" use case should be relatively straightforward to optimize for - back in the early days of the Canvas, we did notice in various profiling runs that static canvas were permanently redrawn, Tom confirmed this and recognized it as lowing hanging fruit to optimize the system - shortly afterwards, we ended up with a new property to "cache" a prebuilt Canvas and not redraw individual elements each frame (IIRC).
:: Back then, this helped optimize the taxiway layer quite significantly. Also, Tom mentioned various times that he's interested in improving canvas performance, especially the upcoming GUI will benefit from such use-case specific optimizations, simply because a GUI is relatively static when compared to a MFD.
:: What the ND/Avidyne code is doing to work around the initialization overhead is to preprocess all imagery during startup. And a number of people have also requested some kind of built-in caching scheme using SQLite - which would basically make it possible to make a canvas persistent and serialize it to a blob. Tom mentioned that he was hoping to work towards this post 3.2
:: In the meantime, you can use one of the SVG tutorials to load a complex SVG file and measure the time it takes to render the whole thing via the systime()/benchmark() APIs. But in comparison to most other Canvas use cases, a livery should be relatively static still. So I wouldn't be too worried about it. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 00:43, 7 September 2014 (UTC) 


::::Excuse me, I'd insert the SVG format only as a simple example to understand the flexibility of my proposal. Canvas However I find it fantastic and definitely want to be taken to implement some instruments in the G91 we are doing. The basic concept is to clarify whether this proposal makes sense, and it may be the key to solving the problems of compatibility between formats. My proposal is an attempt to have the maximum flexibility in size of all the graphic objects in FGFs and make compatible the simulation environment of FGFs in any context. At this point I ask the question to those who can develop in C ++ for FGFs, what I'm proposing is practicable? And What I am proposing can solve the problem of non-free formats? --[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 19:29, 6 September 2014 (UTC)
::::Excuse me, I'd insert the SVG format only as a simple example to understand the flexibility of my proposal. Canvas However I find it fantastic and definitely want to be taken to implement some instruments in the G91 we are doing. The basic concept is to clarify whether this proposal makes sense, and it may be the key to solving the problems of compatibility between formats. My proposal is an attempt to have the maximum flexibility in size of all the graphic objects in FGFs and make compatible the simulation environment of FGFs in any context. At this point I ask the question to those who can develop in C ++ for FGFs, what I'm proposing is practicable? And What I am proposing can solve the problem of non-free formats? --[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 19:29, 6 September 2014 (UTC)
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/75997"

Navigation menu