search

menpo / landmarker.io

Image and mesh annotation web application
https://www.landmarker.io
BSD 3-Clause "New" or "Revised" License
114 stars 21 forks source link

Promises and asynchronous loading of mesh and texture. #61

Closed jabooth closed 9 years ago

jabooth commented 10 years ago

Currently, the landmarker makes many synchronous expensive trips to the server in order to display a textured mesh.

The following two synchronous steps happen when the landmarker loads to cache thumbnails for rapid browsing.

  1. GET /images/assetid - just to find out the size of the image, and if there is one.
  2. GET /thumbnail/assetid - load the thumbnail, now we know the size.

And then, once a new asset is loaded...

  1. GET /meshes/assetid - load the actual mesh geometry
  2. GET /textures/assetid - synchronously load the texture after the fact. Note that only a texture can be placed on a mesh, a thumbnail is just shown as an image placeholder.

Over a slowish-secure connection this number of round trips makes the experience of using the landmarker pretty sluggish.

As a solution to this problem, I've started work on a branch which instead makes the loading of assets totally asynchronous in the landmarker. In the new solution:

  1. The call to GET /images/assetid is eliminated. We just get the image and inspect it to find it's size.
  2. The calls to GET /meshes/assetid and GET /textures/assetid happen asynchronously. If the texture is absent the thumbnail is used as a texture to the mesh - once the texture loads the thumbnail is replaced.

This really improves the perception of the landmarker 'feeling' fast. The work is ongoing and unfortunately had to be left up in the air before I went on vacation, but is largely complete. I would like to revisit it shortly before it bit rots away.

jabooth commented 9 years ago

implemented in release now, see fcd4208778a4dad51c39a63208537a0ec00ddba9 for key changes.