| Summary: | [Patch] Add approximation for display DPI on iOS | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Aaron Barany <akb825> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | amaranth72, dll, icculus |
| Version: | 2.0.10 | ||
| Hardware: | iPhone/iPod touch | ||
| OS: | iOS (All) | ||
| Attachments: |
Approximates DPI for iOS.
Updated DPI calculation SDL_DisplayData-constructor-fix.patch connect SDL_GetDisplayDPI to UIKit_GetDisplayDPI |
||
|
Description
Aaron Barany
2019-11-30 23:22:54 UTC
What situations are you using this for? Sizing of elements in screen space so they are consistent size and adjusting LOD. At least in these cases being off slightly isn't a big deal, but being off by a factor of 2 or 3 is. Isn't that kind of what the DPI-scaled units that iOS uses are for (which SDL uses for window sizes and such, on macOS too)? For example, the iPhone 5s' pixel dimensions are 640×1136, but the OS scales all content by 2x to maintain consistent sizing and positioning of UI elements with other iOS devices while having a different pixel density. So the OS - and SDL - reports the window size as 320x568, and the actual pixel dimensions can be obtained via SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize (and you can divide the pixel width by the DPI-scaled window width to get the scale factor if you really need). Sort of, the code I have uses a reference DPI to adjust the LOD (such as for curve tessellation in screen-space). In order to have this work on iOS with the suggested method, I would need to have a separate code path to compare the two sizes, and also have knowledge of DPI the scale factors are relative to. (165 in this case) It also requires that a window is already created and available in the code that computes the DPI, rather than simply knowing about the screen. It would be more convenient for higher-level code and require less platform-specific knowledge to have a reasonable approximation of the DPI through the same API as other platforms. It seems like we can use the scale factor and the actual pixel reported by the drawable size to get the real DPI. Is that right? If so, that seems like it would be an improved implementation. Unfortunately no, since the resolution doesn't necessarily correspond to the physical dimensions of the screen. For example, an iPad may have the same pixel density (or DPI) as an iPhone, but have a higher resolution due to the larger screen. This is also the case between normal and "+" versions the iPhone. Unless you have a table of specific models, which you'd have to update at least once a year, you don't know the physical dimensions of the screen to find the true DPI. Having a table of models isn't a terrible idea, and unknown models could fall back to some reasonable value... Created attachment 4092 [details]
Updated DPI calculation
I have updated the patch to use a table of current devices and use a computation as a fallback. I have also updated the fallback computation to be more accurate.
Looks good, thanks! https://hg.libsdl.org/SDL/rev/37350f1e7902 Created attachment 4100 [details]
SDL_DisplayData-constructor-fix.patch
I realized I made a minor mistake in my patch: I changed the constructor prototype for SDL_DisplayData, but didn't update the declaration in the .h file. The compiler and linker don't complain, but it would probably be best to fix in case a later change runs into a problem from the mismatch. I have attached a patch to fix this.
Fixed, thanks! https://hg.libsdl.org/SDL/rev/7324ce6b653b This is not functional, as far as I can tell. It looks like the UIKit SDL_VideoDevice (which is internal to SDL) is not getting its GetDisplayDPI field set. The fix is pretty simple (add 'device->GetDisplayDPI == UIKit_GetDisplayDPI;' to UIKit_CreateDevice; I'll attach a patch). Might this have been left out for any particular reason, or is this a bug? Created attachment 4282 [details]
connect SDL_GetDisplayDPI to UIKit_GetDisplayDPI
Also, apologies if reopening this case, rather than opening a new one, is problematic. I can move this to another case if need be. (In reply to David Ludwig from comment #14) > Also, apologies if reopening this case, rather than opening a new one, is > problematic. I can move this to another case if need be. This is right way. (Also, go ahead and push that patch if you're ready!) --ryan. My extra patch is in at https://hg.libsdl.org/SDL/rev/304c6020419a > Might this have been left out for any particular reason, or is this a bug?
This was a mistake: I was working with multiple patches, and this change got dropped by accident when I submitted this component of it. Thanks for catching it.
No worries, and thanks for putting this feature together!! |