Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map does not render unless pitch is set and map is "tilted" #2270

Closed
lsimkins opened this issue Mar 15, 2016 · 18 comments · Fixed by #3740
Closed

Map does not render unless pitch is set and map is "tilted" #2270

lsimkins opened this issue Mar 15, 2016 · 18 comments · Fixed by #3740

Comments

@lsimkins
Copy link
Contributor

Mapbox does not render tiles unless map pitch is > 0 on certain Windows 7 systems. This may be related to #930 but in 930 the map was rendering. In this case, the map does not render anything at all until a pitch is set.

In the screenshots below, the rendering visible on the map is custom GL we've written and render on a separate canvas external to mapbox.

The same behavior also occurs across all mapbox-gl examples at https://www.mapbox.com/mapbox-gl-js/examples/

Map with no pitch set.
blankmap

Map with pitch set to 60.
maptilted

System Specs Screenshot (Processor)
systemspecs1

System Specs Screenshot (Graphics Card)
systemspecs2

mapbox-gl-js version: 0.15.0

Steps to Trigger Behavior

  1. Test any current mapbox example. All examples are blank.
  2. map.setPitch(45)
  3. Tiles render correctly.
  4. map.setPitch(0)
  5. Map no longer renders.

Expected Behavior

Map renders normally.

Actual Behavior

Map does not render unless tilted/pitched.

@mourner
Copy link
Member

mourner commented May 17, 2016

This might have been fixed by #1606 — can you verify with the master branch version?

@blanchg
Copy link
Contributor

blanchg commented May 19, 2016

I can see this happening on one machine and not the other even with a fresh trunk build from an hour ago and v0.18.0

@lsimkins
Copy link
Contributor Author

Very sorry, we don't have an in-house machine that replicates the bug. This was happening on a client's computer that I don't have access to without a visit.

We did overcome the bug by setting the map pitch to an imperceptible 0.01. Hacky but did the trick.

@maptastik
Copy link

I found this issue trying to figure out why the Pokemon GO map shows up on my work machine, but most other mapbox-gl-js maps don't. As far as I can tell, I'm experiencing the same issue on my Windows 7 machine as @lsimkins: mapbox-gl-js maps only render when pitch > 0. When they don't render, there is no error in the console. I've run through many of the examples you all have just to check and pitch seems to be the common factor in determining whether or not the map renders. This is demonstrated in the GIF below taken from the interacting with the map in the example "Fly to a location based on scroll position"
mbgl-win7

var chapters = {
    'baker': {
        bearing: 27,
        center: [-0.15591514, 51.51830379],
        zoom: 15.5,
        pitch: 20
    },
    'aldgate': {
        duration: 6000,
        center: [-0.07571203, 51.51424049],
        bearing: 150,
        zoom: 15,
        pitch: 0
    },
...

The map renders properly on load for the 'baker' chapter where the pitch=20. However, when the map moves and finally settles at the aldgate chapter, where the pitch=0, the map disappears without error.

Follow OP's lead, here are my system and graphic specs:
System Information (Screenshot)
sys-info

Display Information (Screenshot)
gpu-info

I'm happy to hunt down any other information that might be helpful. This is the last real hurdle - beyond learning the thing - to us adopting mapbox-gl-js.

Thanks!

@lucaswoj lucaswoj removed the bug 🐞 label Aug 4, 2016
@peterbodo
Copy link

Hi,

Is this issue already solved?
It has not rendered on my computer with 0.22.1 but works as expected with 0.23.0.

@mourner
Copy link
Member

mourner commented Sep 20, 2016

Possibly! I'm going to close for now then, and reopen in case this is confirmed to still be an issue on 0.24.

@mourner mourner closed this as completed Sep 20, 2016
@peterbodo
Copy link

@mourner Sorry, but it is still an issue, with a colleagues computer with 0.24.

@mourner mourner reopened this Sep 20, 2016
@maptastik
Copy link

I've tested this with 0.24 on Windows 7 and still have the same visibility issue. For what it's worth, I tried using mapbox-gl-js in an Ubuntu 14 virtual box running on the same Windows 7 machine and the library worked fine regardless of pitch. Would that not eliminate the graphics card as a contributing culprit?

After reading the "Fall Cleaning" post it seems using mapbox-gl-js is going to be more and more essential to using Mapbox services. Certainly to get the most out of it! I'm afraid I don't know quite where to begin to try and figure out this bug, but if there's any information I can provide that would be helpful for fixing this, I am happy to run tests and hunt that info down.

@ouchiko
Copy link

ouchiko commented Sep 28, 2016

I'd just add that I had no joy with the graphics card updates and it failed in both Firefox and Chrome (latest v) on Windows 7.. I set the pitch to 1 [ mapgl.setPitch(1) ] and all was good. I added this during the mapgl.on('load', function(){});

@lucaswoj lucaswoj self-assigned this Oct 4, 2016
@lucaswoj lucaswoj added this to the Edinburgh milestone Oct 5, 2016
@lucaswoj lucaswoj removed their assignment Oct 5, 2016
@lucaswoj lucaswoj removed this from the Edinburgh milestone Oct 12, 2016
@jaapster
Copy link

This is still an issue for us with 0.28 on Windows 10 Chrome and Firefox. Edge and IE 11 don't have this problem.

@maptastik
Copy link

maptastik commented Nov 30, 2016

@jaapster I am still having the issue in IE 11.

I've been poking around trying to see when this bug popped up. I looked through about 90 of Mapbox's 'bites' that used mapbox-gl-js to see if there was a time when this library worked where pitch = 0. From what I can tell the issue seems to really show up in the transition from 0.12.2 and 0.12.3. Certainly by 0.14.0 it's a regular occurrence for each version update.

Survey Data:
Mapbox GL JS Bites Functionality.xlsx

Each row in the survey includes the Bite number. To test out, you can use the URL string https://www.mapbox.com/bites/00{Bite}

@dannybloe
Copy link

Due to this bug we cannot deploy for Windows platforms. Please please fix!
👍

@jaapster
Copy link

jaapster commented Dec 5, 2016

I concur with @dannybloe.

Something I noticed is that fill-extrusion layers are not affected by this problem. So while the 2D layers are invisible, the extrusions are visible while pitch === 0.

@mourner
Copy link
Member

mourner commented Dec 5, 2016

While working on refactoring Transform code, I was amused to find out that this bug reproduces on OS X (Chrome) if you replace Float64Array with Float32Array for projection/position matrices. Does this ring a bell @ansis?

I have a feeling that it's the same bug, but it doesn't manifest on non-Windows machines with Float64Array due to some subtle floating point math differences. But now that I can reproduce, I can dig into it.

@mourner mourner self-assigned this Dec 5, 2016
@mourner
Copy link
Member

mourner commented Dec 5, 2016

A temporary workaround that seems to fix rendering for all pitch values is to change map.transform.altitude from 1.5 to something else close to it, like map.transform.altitude = 1.51. Can you guys try this?

@jaapster
Copy link

jaapster commented Dec 5, 2016

Thanks @mourner, this workaround solves our immediate issues!

@mapspiral
Copy link

We would also benefit from a quick permanent fix for this issue! Thanks ever so much.

@mourner
Copy link
Member

mourner commented Dec 5, 2016

Submitted a #3740 with a potential permanent fix. Can you confirm that this hack works too?

ansis added a commit that referenced this issue Dec 13, 2016
This should fix the issue behind #2270 and remove the need for the hack
added in #3740.
ansis added a commit that referenced this issue Dec 13, 2016
This should fix the issue behind #2270 and remove the need for the hack
added in #3740.
ansis added a commit that referenced this issue Dec 13, 2016
This should fix the issue behind #2270 and remove the need for the hack
added in #3740.
ansis added a commit that referenced this issue Dec 14, 2016
This should fix the issue behind #2270 and remove the need for the hack
added in #3740.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants