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

Canvas source errors when larger than some environment-specific size #4262

Closed
lucaswoj opened this issue Feb 13, 2017 · 14 comments · Fixed by #5155
Closed

Canvas source errors when larger than some environment-specific size #4262

lucaswoj opened this issue Feb 13, 2017 · 14 comments · Fixed by #5155

Comments

@lucaswoj
Copy link
Contributor

per @kronick

It seems like canvases over a certain size (which varies by browser, but as small as 256x256 in Chrome) are failing and causing the entire map layer to go white-- this doesn't happen consistently and @lbud wasn't seeing the same issues so my guess is that it has something to do with video memory or the way the texture is created from the canvas

We're going to create some minimal test cases and do some research into known limitations today.

@kronick
Copy link

kronick commented Feb 15, 2017

Here's a debug page I put together to help get to the bottom of this: https://www.mapbox.com/labs/canvas-heatmap/canvas-debug.html

Here's what's expected (red box and green X are rendered to canvas and then placed on map):
image

Here's what the bug looks like:
image

On my 2015 Macbook Pro 13" running OSX El Capitan 10.11.6 with Intel Iris Graphics 6100 1536 MB, here's what I'm seeing by browser:

Chrome v56.0.2924.87:

Resolutions with >= 65,536 pixels (=2^16, equivalent to 256x256) fail

Safari 9.1.2:

Resolutions with >= 524,288 pixels (=2^19, equivalent to 1024x512) fail

Firefox 51.0.1:

Resolutions with >= 524,288 pixels (=2^19, equivalent to 1024x512) fail


On Safari and Chrome on my iPhone with iOS 10.0.1 I do not see the bug at resolutions up to 4096x4096.


@peterqliu checked this out for me on his 2015 Macbook Pro 15" running macOS Sierra 10.12.1 with Intel Iris Pro 1536 MB and was not seeing the bug in Chrome at resolutions up to 2048x2048.

@jliebrand
Copy link

FYI: would have helped out to tell you if I see this in my setup, but the debug page 403s (in the console - failing to get the mapbox dev)

@jliebrand
Copy link

Friendly ping - any update on this?

@mcwhittemore
Copy link
Contributor

mcwhittemore commented Apr 29, 2017

I'm seeing this bug spill into Mapbox Draw tickets. I'm not sure what the status of this is here, but a Draw user provided another fiddle which I'm linking to here in case what is needed to see this move forward is more examples.

Canvas breaks the map
Removing canvas fixes the map

@gpbmike
Copy link
Contributor

gpbmike commented Aug 2, 2017

@kronick

I'm seeing a bug with the same symptoms but it is not dependent on canvas size.

My test case is a 1x1 canvas. Problem occurs when I access the webgl context of the canvas.

https://codepen.io/gpbmike/pen/qXNPOM

I created an issue with more details.

It appears to be dependent on hardware.

Intel Iris Graphics 6100 1536 MB

Chrome Version 60.0.3112.78 (Official Build) (64-bit)

Hopefully this helps a bit?

@gpbmike
Copy link
Contributor

gpbmike commented Aug 4, 2017

I'm seeing this behavior on renderers reported as the following

  • Intel(R) HD Graphics 6000
  • Intel(R) Iris(TM) Graphics 6100

Using the following to get renderer:

const dbgRenderInfo = gl.getExtension('WEBGL_debug_renderer_info');
const renderer = gl.getParameter(dbgRenderInfo.UNMASKED_RENDERER_WEBGL);

Perhaps only affects the Broadwell line of Intel processors https://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics#Broadwell

@jliebrand
Copy link

Another friendly ping; can someone from Mapbox please let us know if this is something that is being actively looked at? It's obviously a deal breaker to go down the canvas route for some of our visualisations if this is not addressed

@lbud lbud self-assigned this Aug 16, 2017
@lbud
Copy link
Contributor

lbud commented Aug 16, 2017

I'm looking into this now. There's an old pre-release build of the canvas source feature where this problem doesn't manifest, so I suspect the answer is somewhere in the diff between 3e36acc and 5082fec — particularly in the possibility that affected GPUs aren't able to use texImage2D/texSubImage2D on HTMLCanvasElements (in the initial implementation we copied canvas data into an ImageData element as an intermediary step).

@lbud
Copy link
Contributor

lbud commented Aug 16, 2017

Out of curiosity, @jliebrand @gpbmike or anyone else who's seeing this issue — are you using the 2d or webgl context type for your use case?

@kronick
Copy link

kronick commented Aug 16, 2017

@lbud iirc, this was happening both with 2D and webgl contexts.

@jliebrand
Copy link

2d in our case...

@gpbmike
Copy link
Contributor

gpbmike commented Aug 16, 2017

are you using the 2d or webgl context type for your use case?

@lbud in my case document.getElementById('canvas').getContext('webgl') is enough to trigger the behavior. See my codepen also linked above.

@lbud
Copy link
Contributor

lbud commented Aug 29, 2017

Fixed in #5155 — if this issue persists after the next release (or using Mapbox GL built from source after 9b7e2e3) please let us know.

@jliebrand
Copy link

Thanks! Out of interest, is there any details as to when or what would trigger a new release? At the moment they seem to just come roughly once a month, but I can't really put my finger on a pattern. Is it "as and when" or is there more structure to it? (and if so, when is the next one? ;-))

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.

6 participants