Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for SDL's handling of "Retina" display on iOS devices #533

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Fixes for SDL's handling of "Retina" display on iOS devices #533

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: iOS (All), iPhone/iPod touch

Comments on the original bug report:

On 2012-01-23 08:22:46 +0000, Tim Angus wrote:

Created attachment 799
Convert usage of UIKit coordinates to pixel coordinates

From the patch:

// When dealing with UIKit all coordinates are specified in terms of
// what Apple refers to as points. On earlier devices without the
// so called "Retina" display, there is a one to one mapping between
// points and pixels. In other cases [UIScreen scale] indicates the
// relationship between points and pixels. Since SDL has no notion
// of points, we must compensate in all cases where dealing with such
// units.

On 2012-01-25 07:05:44 +0000, Tim Angus wrote:

Created attachment 804
Support retina display modes, but retain non-retina display modes

Alright, this new version implements reporting of the "non-scaled" display on Retina devices, i.e. 320x480 as well as 640x960. If the former is selected (using SDL_SetWindowDisplayMode + SDL_SetWindowFullscreen) a scale of 1.0 is used instead of [UIScreen scale].

The only slight gotcha that I've come across is the fact that calling SDL_SetWindowFullscreen unavoidably disables the iOS status bar. I've tried to disconnect the two things but this implies that a window is both fullscreen and its dimensions are not the same as the display mode's. For example, the display mode might be 320x480, but with the status bar enabled the window size will be 320x460. In itself this is fine, but this breaks the wide spread assumption that the two sets of dimensions are identical and with it various other parts of SDL. So I've left that alone for now. It's not really a big deal though, since I imagine most users will want the status bar disabled anyway.

On 2012-01-28 07:34:27 +0000, Sam Lantinga wrote:

Looks good, thanks!
http://hg.libsdl.org/SDL/rev/ed2cf4669e55

On 2012-01-31 07:31:26 +0000, Rodrigo Cardoso wrote:

Thanks for the fix, Tim!
I was looking to try fix this, if nobody get their hands dirty first :)

On 2012-01-31 07:33:13 +0000, Tim Angus wrote:

You're welcome :).

On 2012-02-20 09:40:35 +0000, Tim Angus wrote:

Created attachment 826
Fix for double free when quitting on iOS

It seems I introduced a bug with the original fix for this bug. The new patch fixes it.

As alluded to in the email thread "SDL2 error on iOS (doublefree)", I believe the original cause of this bug is confusion over the purpose of SDL_VideoDisplay::current_mode. It looks as though it is a weak reference to another mode, albeit with value semantics. The iOS port treated it as a strong reference however and claimed ownership, which is why things blew up. All the patch really does it to stop treating current_mode as a strong reference.

To prevent this happening again it might be an idea to change current_mode to be a pointer type rather than a value. This would certainly make its semantics much more obvious. Failing that, a comment in the struct indicating its weak reference properties might be wise.

On 2012-02-20 09:41:04 +0000, Tim Angus wrote:

Reopening.

On 2012-02-20 17:47:06 +0000, Sam Lantinga wrote:

Patch applied, thanks!
http://hg.libsdl.org/SDL/rev/4c25a7b9e819

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant