iOS next sprint

[incanus]

Latest progress here: https://github.com/mapbox/hey/issues/1326

Next goals for me are:

• Get fills working - I believe this is the stencil buffer issue (iOS stencil buffer testing #222).
• Get things running on device. @kkaefer is this just stencil buffer issues, or something else? Do we know? I'm not sure if we have any leads here, so shout out any thoughts you have and I can start investigating. I'm shooting for retina iPad so that we can be sure things work on the most demanding graphical hardware.
• Work off of a more global tileset. This relies on Set up vector tile server #218 public font server. Exploring other areas beyond DC unlocks customer demo potential as well as possibly uncovers more edge cases.
• Solve web worker problem. Right now, we don't use them and fetch/parse vector tiles in the UI thread. Whether this means calling out to async Cocoa code or just porting web workers remains to be seen. (fix async device issues #232)

I'm in the <500 LOC range for all the native stuff I've done so far, so we're not making significant throwaway investments in Ejecta, sticking with JS, Cocoa bindings etc. This is still good work to be doing.

/cc @gundersen @yhahn

[incanus]

Should it be useful, my iOS work is up at gl-ios (6dbfa685f13b683087d988dd4d997b3c66fcbe64).

[incanus]

Per @kkaefer in chat, something else to test out:

btw, there's a sample application in the "ios" branch
that just renders lines with native code
and allows panning/zooming

[incanus]

@kkaefer I checked out the ios branch -- cool.

• I see you just did some basic porting to C++. Were you mostly just getting a feel for iOS/GLKit?
• Any thoughts on using GLKit vs. straight-up OpenGL ES?

[kkaefer]

Yeah, I wanted to see how easy/complicated it is to get OpenGL stuff + interaction running on a device, and it turns out to be pretty easy.

I'd strongly vote for using straight OpenGL ES. GLKit is a nice abstraction if you're doing iOS only work, but it doesn't make much sense for us since our renderer needs to run on many different platforms and we'd have to do a native OpenGL ES implementation (and ship with our own matrix lib etc.) anyway.

[artemp]

+1 OpenGL ES

[incanus]

Fills are now working, as is running on the device. On recent iOS, you don't get a normal stencil buffer, but rather a combination depth-stencil one, so you have to set it up like this:

glGenRenderbuffers(1, &depthStencilBuffer);
glBindRenderbuffer(GL_RENDERBUFFER, depthStencilBuffer);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH24_STENCIL8_OES, bufferWidth, bufferHeight);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, depthStencilBuffer);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, depthStencilBuffer);

That fixes fills -- no JavaScript changes needed.

Next up was errant lines between all drawn lines due to degenerate triangles acting up. @ansis had a hunch it was float precision, and by going from precision mediump float to precision highp float in the line and outline shaders, this was solved.

Other than that, one other problem, but only on the iPhone 5s -- minor labels (i.e. most) are not drawn at all. Changing precision on the label shaders doesn't help, so I'll keep digging. (#231)

Performance on the iPhone 5s is actually very, very good. I'll take an FPS test soon, but I want to work on web workers or otherwise offloading the 2-3s tile load/parse times blocking the main thread right now, then I can put out a device build.

[ansis]

Really awesome to have this working!

and by going from precision mediump float to precision highp float in the line and outline shaders

If possible we should try to keep using mediump floats. Maybe we could try changing the comparison and/or special values so that they work with the lower precision.

[incanus]

If possible we should try to keep using mediump floats.

Yeah, agreed -- will come with performance (and yeah, if possible).

Right now I've almost got working (#232) an async parse of tiles, so next will come this sort of performance...