Touch and Rotation on iOS

SDL Development
1

Hi,

Currently after the phone/tab is rotated. This can easily be checked as
the right side of the screen after rotating from portrait to landscape
stops working entirely.

Right now I am not sure why. I was suspecting that the reason is that
the SDL_Touch object is not updated after the screen rotated, but this
seems to be only part of the problem and only solves the scaling. The
fact that the right side does not respond seems to be a different one.

The whole touchesBegan:withEvent: method is not called at all for the
right screen side after rotation. I tried to see if the problem fixes
itself when I reset the frame of the UIView, but it makes it worse as it
then also does not draw on the right side.

From the docs it seems that the touchesBegin thing might be bubbled up
from the view controller, so I am not sure if that is swallowing the
event somewhere.

Regards,
Armin

2

Hi,

I just found the problem, but I don’t know the solution yet.
Basically locationInView does not work in landscape mode, so I will have
to find something to replace this with.

Regards,
Armin

3

Hi,

Nope, was not the issue. I still think it has something to with the
misaligned UIView.

Regards,
Armin

4

Hi,

Nope, was not the issue. I still think it has something to with the
misaligned UIView.

I’ve found that problem too, but no solution at the moment…

but if you turn the phone upside down at 90 degree per rotation (so doing
landscape -> portrait -> landscape (reversed) ) you get touch sensitivity in
the RIGHT part of the display but non in the left one.

I’ve seen logging touches that they are “captured” since you reach the 319
pixel, so it’s definitely something related to the view rotation (somewhere
there should be a 320 x 480 mask).

An intresting thing is that MOTION events still works after the 319
pixel…On Thu, May 5, 2011 at 8:45 PM, Armin Ronacher <armin.ronacher at active-4.com>wrote:

–
Bye,
Gabry

5

Hi,On 5/6/11 4:34 PM, Gabriele Greco wrote:

An intresting thing is that MOTION events still works after the 319
pixel…
Yep. I noticed the same. I can probably tell you right now why this is
happening but not the solution:

The UIView is not rotated when the phone is rotated. It stays the way
it is so the right part of the screen no longer gets the touch begin
event thingy. However the iOS continues to track the finger movements,
even if the fingers move outside of the component to avoid user frustation.

Now what happens if we update the view rectangle after rotation? For
some weird reason the input still does not work and the rendering is
then also broken for the right part (or left part if rotated 270
degree). To respond to rotations, you can implement updateFrame in the
base view and also [super] the call in the opengl view. The correct
rect is on the window, the wrong one is right now on the view.

Regards,
Armin

6

Hi,

Alright, the problem is definitively the view. SDL does something
horrible there. Things I know so far:

  1. SDL totally fucks up the view frame. It disables auto resizing but
    something still does something in there because the frame of the
    window ends up being different to the frame of the view. If the
    frame of the view is “fixed” all becomes worse as now the rendering
    is equally fucked at that point (right side of screen black).
  2. Whowever wrote that rotation code in SDL had something in mind that
    (no longer?) works as intended. It certainly serves/served a purpose
    but without documentation it’s not quite clear what it does.
  3. Even if it work work as expected, the touch code in SDL would still
    be wrong as it never takes rotations into account.

I came up with a horrible hack that fixes this by doing two things

  1. Ignore boundaries of views and always returns the only view we have
    in the hitTest of the window.
  2. Update the touch internals on rotations.

This is the patch:
http://paste.pocoo.org/show/384923/ [for view]
http://paste.pocoo.org/raw/384923/ [for donwload]

I totally do not recommend to check this in, but at least it’s a
workaround for the moment. I will have to check the history log to see
who came up with the rotation code, maybe something in the log messages
reveals the intent. I certainly must be missing something, because from
looking at that code it does not make a lot of sense. I can’t imaging
that a misaligned UIView is the intention. Right now my idea is that
the badly placed UIView might be an accident and another mistake sortof
fixed that original problem good enough that nobody noticed for a while.

I am quite happy to have a look at that code but I would really need the
input of the original developer to understand why the code is doing
things that way.

Regards,
Armin

7

Hey Armin, that code analysis you provided really helped me in sorting
out his issue; unfortunately i couldn’t use your patch directly
because i add another view on top of the one created by sdl and so
hitTest either stops touch events or is able to dected events
happening only on the first view (skipping all the subviews of my
overlayed view).

So i dug around and found something interesting, that is the uiwindow
frame is somehow cropped at wrong values in sdl_uikitwindow.m; however
why is this needed? after all we own all the surface and despite the
orientation we are currently in we always want to be able to use the
whole screen.

My proposed solution is this:

diff -r 50bf98210aae src/video/uikit/SDL_uikitwindow.m
— a/src/video/uikit/SDL_uikitwindow.m Thu Aug 18 22:43:37 2011 +0200
+++ b/src/video/uikit/SDL_uikitwindow.m Tue Aug 23 02:31:32 2011 +0200
@@ -145,7 +145,7 @@
frame.origin.x = 0;
frame.origin.y = 0;

  • [uiwindow setFrame:frame];
  • [uiwindow setFrame:[[UIScreen mainScreen]bounds]];
    [data->view updateFrame];
    SDL_SendWindowEvent(self->window, SDL_WINDOWEVENT_RESIZED, w, h);
    }

Worked great in my case! Do you think you could try and see if it can
help in your issue?
VittorioOn Sun, May 8, 2011 at 2:24 AM, Armin Ronacher <armin.ronacher at active-4.com> wrote:

Hi,

Alright, the problem is definitively the view. ?SDL does something
horrible there. ?Things I know so far:

  1. SDL totally fucks up the view frame. ?It disables auto resizing but
    ? something still does something in there because the frame of the
    ? window ends up being different to the frame of the view. ?If the
    ? frame of the view is “fixed” all becomes worse as now the rendering
    ? is equally fucked at that point (right side of screen black).
  2. Whowever wrote that rotation code in SDL had something in mind that
    ? (no longer?) works as intended. ?It certainly serves/served a purpose
    ? but without documentation it’s not quite clear what it does.
  3. Even if it work work as expected, the touch code in SDL would still
    ? be wrong as it never takes rotations into account.

I came up with a horrible hack that fixes this by doing two things

  1. Ignore boundaries of views and always returns the only view we have
    ? in the hitTest of the window.
  2. Update the touch internals on rotations.

This is the patch:
?http://paste.pocoo.org/show/384923/ [for view]
?http://paste.pocoo.org/raw/384923/ [for donwload]

I totally do not recommend to check this in, but at least it’s a
workaround for the moment. ?I will have to check the history log to see
who came up with the rotation code, maybe something in the log messages
reveals the intent. ?I certainly must be missing something, because from
looking at that code it does not make a lot of sense. ?I can’t imaging
that a misaligned UIView is the intention. ?Right now my idea is that
the badly placed UIView might be an accident and another mistake sortof
fixed that original problem good enough that nobody noticed for a while.

I am quite happy to have a look at that code but I would really need the
input of the original developer to understand why the code is doing
things that way.

Regards,
Armin

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org