Via @kkaefer: http://i.kkaefer.com/Movie_on_06.02.14_at_19.31.mov

Not impacted by simultaneous recognition like #45 was.

Low priority, but repeatedly two-finger single-tapping to zoom out doesn't queue up all of the events fired during the previous animations, resulting in an end zoom state that's less than desired.

Rotating device changes aspect ratio on the fly and GL context needs to compensate. Disabling in app for now.

• Overall, the map view should be constrained to not show areas outside of the Mercator projection on screen (barring wraparound as done in #14) the same way that it is zoom constrained.
• Then, there should be an API for setting those constraints to an area arbitrarily smaller than the whole world.

a643416

Technically we shouldn't be using GLKViewController since we do our own drawing loop. That class is meant to use a delegate:

When active, rendering loop automatically updates the view’s contents each time a new frame must be displayed. Each frame is rendered by the view controller using these steps:

1. The view controller calls its delegate’s glkViewControllerUpdate: method. Your delegate should update frame data that does not involve rendering the results to the screen.
2. The view controller calls its view’s display method. Your view should redraw the frame.

Since we do all our own drawing, stuff like self.preferredFramesPerSecond = 60 isn't really having any effect.

The existing OS X libllmr.a gets linked ok for iOS simulator testing, but can't be tested on a real device.

Instead of a web-style scroll wheel for zooming & clicking to rotate, gestures should work like 10.9's Maps.app.

low priority

This would be great for debugging.

Lower priority than #34, but Apple & Google do decelerated zoom coasting upon pinch release. Probably involves manual deceleration easing since UIScrollView doesn't do this.

Low priority, but currently the ./configure step does not actually check if the paths to boost/png/glfw3 are valid. So, if they are wrong you'll get a compile error at the make step instead of a nice warning at ./configure. Fixing this will require custom code, since gyp does not bring niceties like this, but should be easy to write when its needed.

Doubt this is relevant given our iOS work is using apple stuff, but this claims iOS support: http://polycode.org/features/

This should operate like other vector maps, i.e. two fingers on the map should allow pinch, pan, and rotate simultaneously without distinguishing between mode changes.

Not sure if this means a custom gesture recognizer or, more likely, allowing them to all call their appropriate APIs simultaneously.

Designated initializers are a c99 feature not officially unsupported in C++/C++11. They are used in the hershey font hack and this code will not compile with g++ on linux. Clang happens to support them but we should not depend on this. You can see that support is a clang c99 extension if you build with -pedantic:

$ clang++ -o t src/geometry/debug_font_buffer.cpp -pedantic -Iinclude
In file included from src/geometry/debug_font_buffer.cpp:5:
src/geometry/debug_font.cpp:3:22: warning: zero size arrays are an extension [-Wzero-length-array]
int8_t simplex_0[] = { };
                     ^
src/geometry/debug_font.cpp:108:16: warning: designated initializers are a C99 feature [-Wc99-extensions]
    [' ']  = { .width = 16, .length = sizeof(simplex_0), .data = simplex_0 },
               ^~~~~~~~~~~
src/geometry/debug_font.cpp:108:29: warning: designated initializers are a C99 feature [-Wc99-extensions]
    [' ']  = { .width = 16, .length = sizeof(simplex_0), .data = simplex_0 },
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/geometry/debug_font.cpp:108:58: warning: designated initializers are a C99 feature [-Wc99-extensions]
    [' ']  = { .width = 16, .length = sizeof(simplex_0), .data = simplex_0 },
                                                         ^~~~~~~~~~~~~~~~~

• Load arbitrary files via HTTP (see #23)
• Parse sprite JSON (202e027)
• Load the sprite image and decode it with libpng
• Create a sprite object that can upload itself to the GPU
• Create stylesheet properties to specify texture
• Add fill shaders from WebGL codebase and enable it in the draw calls

As discussed we need a solid cross-platform build system for the pure c++ core, but that seamlessly integrates with (or at least nests into) platform specific build systems we'll use like XCode on iOS.

Cmake should work fine, but I'd prefer to use GYP since my knowledge of GYP is greater and growing all the time via Node.js/node-gyp/node-pre-gyp usage.

Ideally launchable from the command-line, but that might be pushing our luck with the simulator. This builds on #21 switch to Gyp.

Can't capture in simulator -- see video: https://dl.dropboxusercontent.com/u/575564/Video%20Feb%2004%2C%2012%2050%2052%20PM.mov

Line rendering is needed for streets display.

I seem to recall something like this with the Ejecta approach, too -- @ansis do you remember?

For low zoom levels, the world should wrap.

• Create a pendant to FillBuffer that we can use to store the tessellated lines (see JS/LineVertexBuffer)
• When parsing a tile, tessellate the line. Copy the code from JS from Geometry#addLine
• Port the line drawing code from painter.js
• Make it work
• Respect the line width spec in the stylesheet

@incanus I was told you might be able to whitelist my iOS device on Test Flight. I'm curious to see the GL maps :)

Currently, when rendering into the stencil buffer, we're seeing lots of pointy degenerate(?) triangles running all over the screen:

Instead, they should look like triangle fans that are limited to the bounding box of the feature. Since iOS is using a tiled GL renderer, we should reduce the sleeves that run across the screen (which aren't visible anyway) so that we don't need to process all of the tiles.

For eventual compass tracking mode on mobile.

Currently, the platform::request() is also responsible for generating the URL (which should be part of the stylesheet), and for parsing the data tile. Instead, we should make this a generic HTTP request function and do all the processing directly in the renderer. This involves creating threads for parsing the data tiles in the renderer itself too.

The purpose of this is to have better control on parsing and the associated threads, as well as being able to use platform::request() to request JSON and sprite images too.

We should start a test framework that will run continuously on travis.

I propose we use the single header based catch.hpp which is what I'm using for mapnik-vector-tile.

For mobile gestures.

I started to benchmark the poor performance we have on iOS. To benchmark this, I created a small set of scripts that can programatically generate vector tiles: https://gist.github.com/kkaefer/378bd150fe52de8e74b1

I found that our drawing is completely bound by the CPU. We aren't doing anything fancy on the CPU, so that shouldn't be the case. Instruments revealed that the calls to gleRunVertexSubmitARM are taking up most of the time. This function shouldn't be called by glDrawArrays because it means that it's transferring all vertices to the GPU on every frame, which of course bogs down rendering tremendously.

I'm not sure why this is happening. Does anyone have ideas?

@ansis have you been able to get this set up? Is it going to be practical to develop this project on your linux-box?

I'm curious what the rationale behind using GLFW is. In my mind, the benefit to going native is support on mobile and embedded systems, but GLFW is currently designed for desktop platforms:

Currently, GLFW supports Windows, OS X and Unix-like operating systems with the X Window System, such as Linux and FreeBSD.

There is a brief nod to OpenGL ES on the homepage but not great progress on iOS so far:

Hello.
This is possible to use GLFW to build for iOS?

No.

Asking because I'm wondering if it makes more sense to port GLFW to iOS or to go at things directly. Coming off of the Ejecta work, I'm not relishing another intermediary platform for unclear benefit reasons.

We could optimize vertex buffers by making sure we don't duplicate any vertices because we're using indexed draws (with drawElements) everywhere anyway. This reduces the memory, bandwidth and allows the hardware to the transformed vertex cache so it only has to transform a vertex once.

To better use that cache, we should sort the vertex and index buffers so that we avoid large jumps: ideally, indices are as linear as possible. To achieve this, we can reorder the vertex cache.

• 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.

Particularly now when performance hasn't been tuned, it would be good to know when tile load/parse activity is happening with the status bar spinner.

Involves tying a dummy UIScrollView delegate to the CADisplayLink render pass.

Per @kkaefer:

When zooming in, this always moves back to an intermediary state for me, like snapping to integer zoom levels or something.

http://i.kkaefer.com/Movie_on_06.02.14_at_15.53.mov

We should clear the vertex arrays we build in CPU RAM after we uploaded the data to the GPU. They aren't used after we upload anymore and just take up memory.

In fixing #46, pinches are now very slightly off. @kkaefer explains this well:

http://i.kkaefer.com/Movie_on_06.02.14_at_21.38.mov

Something I'd like to see is applying marker imagery points on the map, using a quad tree for efficiency, anti-rotating against angle changes to remain upright, and supporting z-indexing (markers closer to the bottom of the screen are in front of those closer to the top).

Basic POIs are done over in WebGL:

• mapbox/mapbox-gl-js#43
• https://github.com/mapbox/llmr/blob/master/js/render/drawpoint.js
• https://github.com/mapbox/llmr/blob/master/shaders/point.vertex.glsl
• https://github.com/mapbox/llmr/blob/master/shaders/point.fragment.glsl

What I want is the ability to replace this from the SDK:

https://dl.dropboxusercontent.com/u/575564/rotatepins.mov

I'm going to start working on this.

See https://github.com/mapbox/llmr-native/tree/ios, in particular the README.

Our line pattern shader performs dependent texture reads. The word "dependent" is slightly misleading, as it typically refers to using the result of one texture read as input to another texture read. However, in our case it refers to us performing lots of calculations before we use it as an input parameter to the texture read.

that was ported from another todo list. it applies to double-click zooming - in webgl there was a timed fade animation rather than 1->0 opacity change

When backgrounding the app or sleeping the device, on wake the screen is black until you make a gesture. Relates to the view controller's pauseOnWillResignActive defaulting to YES and needing to listen to the app foregrounding and run an update.