v1.9.0 add "fill-extrusion-pattern" webgl is not working properly

[nuancheng]

The latest version adds 3D architectural texture, and the webgl is not working properly
V1.8.0 is normal

mapbox-gl-js version: v1.9.0

browser: Google Chrome 80.0.3987.149

Steps to Trigger Behavior

1. v1.9.0 "vector" layer add "fill-extrusion-pattern" img

Link to Demonstration

"fill-extrusion-pattern": { property: "height", type: "interval", stops: [[40, "catcat"]] },

wrong：https://jsbin.com/yazutumoxa/edit?html,output
Expectant：https://jsbin.com/yazutumoxa/3/edit?html,output

Expected Behavior

Actual Behavior

[nuancheng]

wrong url：https://jsbin.com/kiyarubuji/edit?html,output

[mourner]

@karimnaaji might be related to the change in #9372?

[karimnaaji]

I checked the sanity of #9372 to see if it introduced a regression. There are no regression introduced by this specific PR, though, while looking at that I found another bug, which is in the vertex layout of pattern attributes.

Explicitly setting this offset to 0 assumes that all vertices within this layout start at the same byte in the vertex format. This is incorrect since this layout has 4 different components, each of which starts at byte offsets 0, 8, 16 and 17. This may have been silently broken for some time and adding new attributes in this layout did not take effect for DDS.

For this particular issue, @nuancheng , you need to use addImage with {pixelRatio: 2} option since you are loading a @2x image manually, the difference is that in v1.8.0 we were using the device pixel ratio, which happened to match this 2x on a 2x screen. So this example will actually accidentally work under a 2x screen in v1.8.0. But, on my 1x screen this image pixel ratio is downgraded to a 1x incorrectly in v1.8.0:

Using addImage with {pixelRatio: 2} will work as long as you are not using data driven expressions in fill-extrusion-pattern; for DDS that's a good thing you brought this issue up, I'll be submitting a PR very soon with a fix and render test coverage around it.

[nuancheng]

As if we are not talking about the same problem, I mean the error of v1.9.0 shown here

But it only appears on Mac OS. It looks normal on windows

[karimnaaji]

We are talking about the same problem and I understand what you are trying to show, I tried to give you details so you can follow us there. The path forward would be taken from #9482.

Can you give more information on these new screenshots? The code is truncated and I'm wondering whether you used the same as the initial examples as I can't repro the first screenshot; it makes it hard to make any assumption about how it's being used.

Here is your code snippet with the fix: https://jsbin.com/dagixugazi/edit?html,output

[Plantain]

Possibly related as suggested in #9394 , previously zooming would keep scaling of fill-patterns relatively constant, now it gives visually distorted/broken behaviour, see an example of zooming below with:
'fill-pattern': ["concat", "bs_", ["to-string",["get", "idx"]]],
where idx varies across a few different patterns (the area shown is one pattern though).

Behaviour now, before and after zoom:

Behaviour previously, before and after zoom:

[nuancheng]

https://jsbin.com/dagixugazi/edit?html,output
The problem has been solved in this version. Thank you.

In addition, I want to ask you a question. Now after the building is pasted with texture, the magnified texture of the field of vision will be recalculated. Is there any way to prohibit recalculation?

15 <zoom< 16 :

16< zoom < 17 :

The texture effect varies greatly under different zoom, which makes people feel a little strange.

[karimnaaji]

@Plantain Thanks for the details, using 'fill-pattern': ["concat", "bs_", ["to-string",["get", "idx"]]] will lead to the same code path and should be fixed by #9482. Make sure to use the appropriate pixel ratio when using addImage, if you happened to be using it.

@nuancheng I think we will need a better example, using the full atlas of icons was ok to exemplify the issue you initially opened but does not give an appropriate representation for what you are suggesting. Can you open another issue applying a texture that would seamlessly repeat to better express this?