radioman10 Definitely would not force JPG and leave an option for PNG. However, I think we can safely omit all other image export formats. The philosophy of the new WSV3 is to do the most useful things very well as opposed to a low-quality implementation of a bunch of useless options. This is core to the overriding Data Oriented Design philosophy which has guided me since 2021, when I first watched Mike Acton's famous 2014 CppCon talk. Even the aspect of writing a highly performant, specialized Windows-based PC GPU graphics program instead of a bloated web application is an example of this principle. So getting back to the high-level application, JPG and PNG export, and the broadcast version will have extensive automation abilities to trigger a command line/batch file if you need to do more than that. Getting back to the philosophy for a second, you can see why this is so useful in a world where we have things like ImageMagick for absolutely free. No need to bloat the software reinventing the wheel. It should offer a highly optimized experience to accomplish the bare minimum requirements and, in the broadcast version, allow for automation/command line execution for custom processing after the fact, where you can use open-source, easy solutions.
I want to revisit your great ideas for the screenshot saved indicator. This is one of many areas where something like this will be useful, so it's something I need to wait until I can understand better in relation to those other areas. This will likely be connected with the HUD/text/vector graphics system, which I haven't created yet beyond the very simple V6P hard-coded city label rendering example.
Same is true for video export: how this works and all the options are partitioned depends a lot on the broadcast functionality/version, which I am nowhere near. For the non-broadcast primary version which I still want to keep in the current $25-30/month range, I do not want to deprive the user of manual video export. Actually, I want to make it faster and easier to use. I will likely have to force a small watermark to justify allowing broadcast-quality weather graphics export at consumer prices, which is an idea I was previously resistant to. However, let me opine more on philosophy with the sandwich analogy:
I want to subdivide the different versions of WSV3 Tactical Mesoanalyst 2025, from low-cost consumer to industrial/TV broadcast, like cutting a sandwich vertically and NOT horizontally. Instead of only getting bread and no meat in the smaller cuts, I would rather everyone get a lesser dose of the maximal experience (advanced 3D rendering, value-added streaming server-side compressed data products, highly customizable graphics and friendly export graphics usage rules for individuals, etc) than give fuller doses of a more limited experience.
As it concerns the video export feature, an example of this is allowing and even encouraging it on the personal, non-broadcast license, but adding a watermark to drive sales to keep the price for consumers low and further differentiate between the industrial version.
Anyways, getting back to the indicator idea, here is another requirement I already considered for a status indicator. Each map needs to have a concept of "loading" vs "loaded". This logic will be of utmost importance in any broadcast version, where preloading hot data into memory for rapid transitions is required. It also plays into the tactical-grade low-power-optimized rendering engine design where the product only uses the GPU to render frames when something is changed - camera view, data load status, and remaining animation effects being three large categories. When you merely move the map, somewhere there needs to be an indicator that briefly goes from "loading" to "loaded". When you first run the software and it needs to download a lot of mapping data, there should be a clear indicator the map is still loading raster and vector tiles. I already have this half-working where it stops rendering after new tiles are loaded, however it still does full-framerate rendering during the loading period itself instead of constraining to new texture/etc loads, efficient logic which will be added. This is similar to the concept of "edge computing".
As for UI indications of "map loading", I thought of maybe a green vs yellow circle in the upper map tab. It's possible it could be in the on-map HUD as well. Need to think of this in the context of other small status indicators like the one you proposed. There will likely be others. I want there to be a on-battery indicator and automatic switchover between power/graphics modes based on plugged-in-or-not. Lots of ideas to ruminate. Thankfully, the UI and on-map HUD are going to come last in development, due to the order of dependencies, so we have a lot of time to think about this.
