loading the 2d images for base map is heavy

[antont]

@Stinkfist0 reported that on his computers the initial load of 2d map images is the current perf bottleneck - stalls a compu for even 20secs before the images are loaded and then normal use works ok.

this is not too surprising as those map images are a quite a lot of data and are processed in a perhaps bit heavy way to gl textures.

i bet e.g. loading DDS textures directly might be lighter.

vizi 0.1 didn't have this prob as it didn't use textures at all in fact but created the roads also as 3d geom .. which, weird enough, is I think faster and lighter.

this is not a showstopper but if / when we get to perf optimizations seems worth a check if this bottleneck can be improved.

even pre-converting to DDS and hosting the required set of tiles ourselves (in s3 or somewhere) might be worthwhile - Adminotech's Meshmoon asset service which can automatically convert etc. might help there.

[jonnenauha]

If you are using vizicities and have the chrome (or any other) browser dev
tools open. I recommend enabling HTTP cache. On chrome you can find it from
"network" tab and uncheck "disable cache".

Many times developers keep this checked so they get latest scripts on F5
after mods to the sources. However this will also disable caching the API
responses that vizicities does. There are tons of request at the start.
Enabling the cache them should help.

If you are using "grunt dev" in our app repo to host the local environment,
that http server will never return 304. So even if chrome cache is enabled,
you should never get stale source files from what you are developing in the
repo.

Note that using incognito mode disabled cache as well, I am not sure if you
can even enable cache in it. I recomment using normal chrome tabs.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.
www.meshmoon.com

On Thu, Dec 11, 2014 at 3:26 PM, Toni Alatalo [email protected]
wrote:

@Stinkfist0 https://github.com/Stinkfist0 reported that on his
computers the initial load of 2d map images is the current perf bottleneck

• stalls a compu for even 20secs before the images are loaded and then
  normal use works ok.

this is not too surprising as those map images are a quite a lot of data
and are processed in a perhaps bit heavy way to gl textures.

i bet e.g. loading DDS textures directly might be lighter.

vizi 0.1 didn't have this prob as it didn't use textures at all in fact
but created the roads also as 3d geom .. which, weird enough, is I think
faster and lighter.

this is not a showstopper but if / when we get to perf optimizations seems
worth a check if this bottleneck can be improved.

even pre-converting to DDS and hosting the required set of tiles ourselves
(in s3 or somewhere) might be worthwhile - Adminotech's Meshmoon asset
service which can automatically convert etc. might help there.

—
Reply to this email directly or view it on GitHub
#7.

[antont]

thanks for dev tips -- i actually haven't really suffered from this, takes only a few seconds or so for the demo to become usable (on 2 year old laptops but with ssds and i guess decent pipelines, i5 mac & i7 dell). perhaps caching will help Ali.

but the main point here is about the end user experience. and there typically it's the first time so cache doesn't help. so if we can in the end make the initial load & start experience better for 1st login that'd be good.

as a benchmark, i just tested looking at 'Ruanda' in gmaps (haven't looked that before :) and it was usable in a second.

i don't think the current situation is awful (at least on modern compus) but just put the note here for record as Ali helpfully reported what AFAIK is the current bottleneck where we can perhaps improve at some point.

[Stinkfist0]

The most important things is how this works on regular users with vanilla browsers. "Enable some dev flag to make our app work ok" instruction overlay is not preferred.

[antont]

i tested this a bit and started to wonder

.. is it actually much due to the downloads simply taking time? i guess that's what @jonnenauha told as said how caching helps (i usually run with incognito to avoid caching when devving)

so dds wouldn't be faster if png is faster to download, and actually the load & conversion process then on the cpu and to the gpu isn't that much of a prob?

ofc best to see and profile etc if actually plan to do something with this now.

perhaps a trick to make dev experience faster is to just disable the image usage? iirc @Stinkfist0 tested that then and told it became fast.

[antont]

oh - tested by disabling the map images and the whole thing became much faster also otherwise .. the shader effect wave thing that happens when move is nice and fast now even on this hd4000 old laptop thing

interestingly enough the screenshot that ludo just shared about a darker style looks similar :)

but i think i'll keep this disable locally when dev on weakish laptops

´´´
//var switchboardMap = new VIZI.BlueprintSwitchboard(mapConfig);
//switchboardMap.addToWorld(world);
´´´

in https://github.com/playsign/fidemo/blob/master/main.js#L377

[jonnenauha]

@Stinkfist0 Obviously my tips was for developers running on the scene locally and dev tools open. Normal uses will have caching enabled, but devs might not realize its disabled when dev tools are open or you are using a incognito tab (which many web devs use to make sure nothing comes from cache).

End users will have the normal web experience like they do on any other page. The map queries will be cache by Chrome via the normal HTTP cache mechanisms. But this wont help for the first load, as Toni noted only way to improve that is to make the payload smaller and/or reduce the number of requests.

Devs having dev tools/incognito tab open will have the "worst case scenario" each time they hit F5 because the map requests are disallowed from using the HTTP cache, which makes thee page slow down. My tips were to eliminate this problem when devving, while still getting non cached versions of the app you are touching locally.

Edit/btw: There is no way to speed up the load with a incognito tab, it never uses the cache. You can use a normal tab and setup the options as I suggested.

[Stinkfist0]

Ah, misinterpreted a bit. But how is the regular end user experience at the moment? afaik annoyingly slow on the first time nevertheless.

[jonnenauha]

Yeah, it varies a lot for me. Sometimes the map comes right away and sometimes it takes 2-10 seconds of showing black under the buildings etc. before it pops in.

You have to remember that each site/domain/the cache in general has limits. If you start looking into it the overall chrome default cache size is not that much. You can check chrome://net-internals/#httpCache "max size:" from there as bytes. For me it is 320mb.

I'm not sure if each domain/page has its own limits. But in eg. WebOulu I noticed that all the assets in the initial load + a few blocks of the detailed model did not fit into the http cache. Next time you login it failed to get 304 responses as the older items were being destroyed last time you visited :P

I dont see these small jpeg/pngs doing this for us however. looks like they are very small. Anyways something to keep in mind.