We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Created attachment 1991 [details]
Major improvements and bug fixes for iOS

I have attached an updated patch which has several new changes and improvements - mostly reworking some internals of the window and view behavior in the UIKit backend, and also re-adding support for the custom extended launch screen, this time with code that has the proper fallbacks for pre-iOS 8 and doesn't mess up the window orientation.

The changelog in my original comment above is now obsolete, but the new patch contains a new complete changelog / commit message near the top (the patch is in the HG changeset patch format, so it lists my commit message.)

Created attachment 2005 [details]
Major improvements and bug fixes for iOS (version 3)

I updated the patch again, to fix a minor visual glitch that would happen in rare circumstances with the old patch when the screen was rotated after the extended launch screen finished displaying.

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!

For reference, here are some bugzilla reports that are also fixed by this patch:

https://bugzilla.libsdl.org/show_bug.cgi?id=2212
https://bugzilla.libsdl.org/show_bug.cgi?id=2826
https://bugzilla.libsdl.org/show_bug.cgi?id=2661 (I believe)
https://bugzilla.libsdl.org/show_bug.cgi?id=1885
https://bugzilla.libsdl.org/show_bug.cgi?id=1578
https://bugzilla.libsdl.org/show_bug.cgi?id=2751

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.

Created attachment 2114 [details]
Major improvements and bug fixes for iOS (version 4)

The patch has been updated to apply without merge conflicts to the latest SDL source code. The patch's changes are listed at the top of the diff file in its commit message, as usual.

I also have a public repository with the changes here: https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements (in the iOS-improvements branch of that repository.)

(In reply to Alex Szpakowski from comment #6)
> Created attachment 2114 [details]
> Major improvements and bug fixes for iOS (version 4)
> 
> The patch has been updated to apply without merge conflicts to the latest
> SDL source code. The patch's changes are listed at the top of the diff file
> in its commit message, as usual.
> 
> I also have a public repository with the changes here:
> https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements (in
> the iOS-improvements branch of that repository.)

I would rather have this split up into multiple commits, to avoid having a single changeset with a commit message of "here's a million things that suck less"; is there any reason to not just pull from your repo instead of working from the patch posted here?

One initial note, though:

SDL_iOSGetViewFramebuffer and SDL_iOSGetViewRenderbuffer: can we just put these into the SysWM structure? Sometimes iOS-specific APIs were unavoidable, but I'd rather not add new ones if we don't have to, and syswm is basically designed for this.

(Eventually, we might offer a generic "give me the window system's FBO" since it's zero on some platforms and an FBO that SDL generated on others, but that's for later.)

--ryan.

(In reply to Ryan C. Gordon from comment #7)
> I would rather have this split up into multiple commits, to avoid having a
> single changeset with a commit message of "here's a million things that suck
> less"; is there any reason to not just pull from your repo instead of
> working from the patch posted here?

I was just worried that "here's a million commits at once" might not be desirable, but if you're fine with that then the repo should be fine. :)

> 
> One initial note, though:
> 
> SDL_iOSGetViewFramebuffer and SDL_iOSGetViewRenderbuffer: can we just put
> these into the SysWM structure? Sometimes iOS-specific APIs were
> unavoidable, but I'd rather not add new ones if we don't have to, and syswm
> is basically designed for this.

Ah, I didn't think of that – there should be no problem with that, I'll do it now.

If you do prefer the repository instead of the giant patch then I'll just push to there without attaching a new patch here every time.

(In reply to Alex Szpakowski from comment #8)
> > SDL_iOSGetViewFramebuffer and SDL_iOSGetViewRenderbuffer: can we just put
> > these into the SysWM structure? Sometimes iOS-specific APIs were
> > unavoidable, but I'd rather not add new ones if we don't have to, and syswm
> > is basically designed for this.
> 
> Ah, I didn't think of that – there should be no problem with that, I'll do
> it now.

One potential issue is that if code uses 2.0.3's SDL_syswm.h header but 2.0.4's UIKit_GetWindowWMInfo, then things might crash (SDL would try to modify memory outside of what the code using SDL considers the size of the SDL_SysWMinfo struct to be.)

Since SDL for iOS is only set up to be a static library though (for now), that isn't such a big deal, right?

Nevermind, I implemented a check using the version members of the SDL_SysWMinfo struct. Sorry for the noise!

The repository has been updated with the change: https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements

(In reply to Alex Szpakowski from comment #10)
> Nevermind, I implemented a check using the version members of the
> SDL_SysWMinfo struct. Sorry for the noise!
> 
> The repository has been updated with the change:
> https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements

Ok, this is in our repo now, and the named branch is marked as closed.

Nothing quite like landing thousands of lines of changes before finalizing a release!  :)

Resolving this bug (and several others).

--ryan.

Hey, Alex, Bug #2660 is fixed by this too, right?

--ryan.

It should be I think, yeah: https://hg.libsdl.org/SDL/rev/bff6f1fecc5d


I also just pushed a couple orientation fixes to my SDL fork ( https://bitbucket.org/slime73/sdl-experiments/commits/all ), if you don't mind pushing them to the main SDL repository.

(In reply to Alex Szpakowski from comment #13)
> It should be I think, yeah: https://hg.libsdl.org/SDL/rev/bff6f1fecc5d

Thanks!

> I also just pushed a couple orientation fixes to my SDL fork (
> https://bitbucket.org/slime73/sdl-experiments/commits/all ), if you don't
> mind pushing them to the main SDL repository.

Merged and pushed.

--ryan.