General stability and performance improvements.

Would it be possible to give a broader explanation for this statement that is at the bottom of each beta release and other releases as well?

It seems odd not to explain what the stability and performance improvements actually are without listing them in detail like the other portions of the update.

If it isn't relevant, then why include it? If it is relevant, why not give us some information on where to see the stability and performance improvements.

If it only affects certain GPUs or other specific hardware, then why not list that information?

Thanks,

Erik

Wondering if something like this: https://www.videolan.org/developers/vlc-branch/NEWS will make more sense to you?

Logs like these would actually be great, yeah.

Yes Daniel, I agree that the information example your provided is helpful while accepting it is difficult and complex at times. However, if such a detailed list of information exists for BMD releases, it could be helpful to post it for others who are having specific problems\issues. It would give some transparency on areas where BMD is working to provide better software.

Erik

Hi Erik,

I strongly believe that providing a comprehensive list of bugs fixed in a particular release for an application such as Davinci Resolve is an unnecessary effort. You can see how many problems are reported here in the forum and if you're not into the software development industry you cannot imagine how many issues are reported (and fixed) during the internal QA process - mostly edge cases (like using a specific version of a driver for a specific video card with a specific version of a codec for a specific camera model) that are not going to affect the general user at all.
In my humble opinion if you have a specific problem it will be much easier for you (and for Blackmagic ) if you just download the new release and check for yourself if it is resolved or not (instead of digging into the changelog and trying to guess - in most cases the tickets that are opened to the developers will be rephrased) and report it back if not fixed.

The bottom line is it's not relevant. But if BMD left it out, there are a lot of whiners who would say "That's all? You spent three weeks working on things and have 8 bullet points to report?" So it's more of an assurance that they've been doing lots of stuff to improve the product, including fixes that the developer may have no clue whether users can perceive the change, but it is an improvement and it does fix potential issues and it does make future fixes less likely to break something.

That's how software development works. A coder may be refactoring code to make it more robust. They have no idea how that change will play out across the entire program, nor even if the change will be perceivable to users. But it is making things more reliable, making future changes faster and simpler to make, perhaps improving efficiency, and so on. One person could spend their entire three weeks doing that. So does BMD leave it out as if there hadn't been considerable effort expended to improve the product?

It's not odd at all, it's an acknowledgement of hard work and improvement in the many cases that don't have a handy, concise, user-understandable narrative available. (And I'd much rather developers develop and not have to spend their time trying to figure out how to write compelling narratives.)

You might say, "So why not just use raw developer tickets and let us sort through the small fraction that we understand as end users?". Problem is that, too will lead to lots of friction and wailing. Someone updated the "H264_util_lib_xyz" to use 1.0.0.3 instead of 1.0.1.2 and users with dozens of different kinds of H.264 issues will all chime in, "You said you fixed H.264 issues but you didn't!". It's more confusing than helpful.

(And this isn't just a "People who don't know how to code can't possibly understand this stuff" argument. Even a very experienced developer who is not familiar with Resolve's code base -- and probably few BMD developers who work on Resolve actually have an understanding of most of the code -- couldn't make sense of half of the internal tickets. They'd all be familiar-looking, but judging the end-user impact would still be nigh-impossible.)