HDR support, fixes #255

[romkal]

This should fix the #255. I observed the same problem and although this is a dirty workaround, it works well enough. For sure better than the flashing.

[psieg-jenkins]

Can one of the admins verify this patch?

[psieg-jenkins]

Can one of the admins verify this patch?

[romkal]

Actually now it seems to me like a bug in the OutputDuplication as it seems it doesn't do any format conversions if the only update after getting a new frame is the cursor position. I couldn't find it documented anywhere, but...

Once I added the code that checks for LastPresentTime == 0, we can always recognize the format and never get the infamous DXGI_FORMAT_R16G16B16A16_FLOAT .

[romkal]

For reference: https://docs.microsoft.com/en-us/windows/win32/api/dxgi1_2/ns-dxgi1_2-dxgi_outdupl_frame_info

[psieg]

Thanks for spotting this! It seems the problem is simpler than it looked :)

[romkal]

I've just realized I have no idea how to mark this pull request as fixing #255 ...

[FluffyDiscord]

Oh my god this is huge, can anyone build a release please?

[psieg]

@romkal you did associate it by mentioning the issue number in the PR description.

I'll make a release today.

[Benik3]

WOW, thank you so much! I already had prepared solution with converting it with QT (because QT6 has finally ability to make HDR pictures).
In my opinion it's obvious bug in DDUpl, I already reported it to microsoft, nothing changed:
https://docs.microsoft.com/en-us/answers/questions/179015/duplicateoutput-doesn39t-convert-format.html?childToView=181497#comment-181497

[romkal]

You might argue that this is an optimization. If nothing changed, why to even do the work of converting the buffer.
Still should be clearly documented and not require almost a salt of luck to figure it out.

[BtbN]

I just found this one by chance, and it FINALLY made me realize what on earth is going wrong with ddagrab in FFmpeg, so thanks for that!
Related patch: FFmpeg/FFmpeg@21c6d12
(I picked a bit of a different approach, to not miss pointer updates, and copy the entire texture to a buffer to use in those cases...)

I had legitimately spent months wondering what the hell is going on, and why ddagrab sometimes randomly decides to change the output format to one not even supplied to the initial list of supported formats...
Yeah, I totally agree that this is most definitely a bug on the Windows-Side of things. It seems to skip format conversion on frames without an update.

This whole thing makes me wonder if one isn't even supposed to use the desktop resource/texture on those instances, and the API considers it invalid. Meaning it works for 8 bit by pure chance for a whole lot of applications.