WinRT changes for review |
WinRT changes for review |
DLudwig
|
Thanks for the patch. I have a few questions and comments about it:
1. regarding DPI, the diagonal-DPI computation looks odd to me. Is this returning the same values that the SDL's Win32 backend would return? 2. regarding buffer-count: any thoughts on if that were moved into a hint? 3. for remembering window-fullscreen, does SDL need to be modified in order to support that? Could that be handled via app code, or via an extension library? Cheers, -- David L. On Sun, Oct 2, 2016 at 5:20 AM, hardcoredaniel wrote:
|
|||||||||||||
|
WinRT changes for review |
hardcoredaniel
Guest
|
Hi,
let me put my answers here: 1. I have not found anything useful to put into ddpi. I filled in the value for "ResolutionScale", but I do not know whether the raw DPI values need to be scaled anyway - so this was experimental only. I can also put in the mean of rawdpix and rawdpiy instead. 2. I would be fine with a hint, one reason less to maintain an out-of-tree SDL :-) Last time we discussed it we did not conclude whether the hint is necessary, or triple-buffering should be enabled by default, because the additional memory consumption is not relevant nowadays. 3. The implementation from the patch will only try to set the "PreferredLaunchWindowingMode" property if the switch to windowed/fullscreen worked. An implementation outside SDL would have to query the fullscreen state first (to check whether the call worked) and then set the property accordingly. However, if the property should be set independently of the result of the function call, it can be set externally. Too bad that "SetWindowFullscreen" cannot return success or failure... Regards, Daniel ---------- Původnà zpráva ---------- Od: David Ludwig Komu: SDL Development List Datum: 2. 10. 2016 17:09:45 Předmět: Re: [SDL] WinRT changes for review
|
|||||||||||||||
|
WinRT changes for review |
DLudwig
|
On Sun, Oct 2, 2016 at 3:04 PM, hardcoredaniel wrote:
If those values give return values that are equal to the values returned by the Win32 backend, I'd generally be fine with this. Â
I've started work on a patch (for a hypothetical, SDL_HINT_RENDER_BUFFER_COUNT), and will try to post it to Bugzilla soon, for review. Â
Having internal SetWindowFullscreen functions be able to report errors sounds interesting. I'm wondering if there are downsides here, such as quirky behavior on select platforms (I vaguely recall OSX-fullscreen'ing being async, for example), that would prevent this operation from making sense, in some cases.  :-/ -- David L. |
|||||||||||||||||
|
WinRT changes for review |
hardcoredaniel
Guest
|
On Sun, Oct 2, 2016 at 3:04 PM, hardcoredaniel wrote:
No, currently they are not. I put in the numeric value of this enum instead: https://msdn.microsoft.com/de-de/library/windows/apps/windows.graphics.display.displayinformation.resolutionscale.aspx My impression was that the DPI values need to be scaled by this. (Like iOS physical DPI changes depending on whether you request a highDPI window or not). But maybe this is not true. If these values https://msdn.microsoft.com/de-de/library/windows/apps/windows.graphics.display.displayinformation.rawdpix.aspx https://msdn.microsoft.com/de-de/library/windows/apps/windows.graphics.display.displayinformation.rawdpiy.aspx are always correct, then I can simply copy&paste from the Win32 backend to compute ddpi.
Cool :-) Please announce your patch on the list as well so I can take a look.
Hm, in that case a "get()" function for the fullscreen state would probably be a better idea than a success/failure return value from the "set()" function.
|
|||||||||||||||||||||||||
|