Only render when we need to

[kkaefer]

• On OS X, we currently attempt to only render when we need to. This fails sometimes, e.g. when we parsed a new tile, but the user doesn't move their mouse or does any other action, we're not going to show the new tile.
• On iOS, we're currently trying to render as fast as possible without regards to whether we actually have any changed state. We should not do this.

[incanus]

Assuming that on iOS, this means a move to a dirty flag which necessitates a call to render()?

[incanus]

We should be able to solve this on OS X by posting an NSNotification upon tile load success which calls render().

I will work on iOS first -- this should move to a CADisplayLink for UITouch tracking + the above notification approach for tile loads.

[kkaefer]

@incanus I've had got success setting paused = true on the GLKViewController on iOS.

[incanus]

I was experimenting with pausing the CADisplayLink directly, but pausing the VC is my next bet.

[kkaefer]

[self performSelector:@selector(stopRender) withObject:nil afterDelay:3.0];

why do do this?

[incanus]

Yeah I've been thinking about this, that it's somewhat unconventional, and how to best start/stop rendering. This buys a few seconds of render passes after significant actions (gestures, tile loads, etc.) which had caused an update. We may be able to just stopRender directly, or possibly with afterDelay:0, which means the next pass of the run loop.

I will reopen this to flag that I should take another look -- was just on my mental todo before.

[incanus]

Nah, this is a good way to do this. Actions which require render updates (gestures, tile loads, etc.) un-pause the display link passes, as well as cancel previous requests to re-pause the passes. Once things die down, a (three second) future re-pause call kicks in and stops renders until the next significant action.

[kkaefer]

I'm concerned that 3 seconds is an arbitrary value. Instead, we should algorithmically determine if we need a rerender (like on WebGL).

[incanus]

Ok. Lower priority, but I'll take another pass at this. We might be fighting GLKView's own benefits.

[incanus]

This is superseded by #161.

[kkaefer]

This is also done by moving to libuv, so not related to GLKit (which is iOS specific anyway).