You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mapbox-gl doesn't use browser provided antialiasing. Instead we antialias layers ourselves by blurring edges, etc. We haven't revisited this decision recently. I think the original reasons for not using browser provided antialiasing were maybe:
it isn't supported everywhere (it depends on drivers, etc)
performance. We thought it might be cheaper to do it ourselves (I'm not sure if we've ever measured it though!)
Since we are not requesting antialiased contexts custom layers don't have access to browser-provided antialiasing.
Even if we were creating contexts with antialiasing, we currently render custom layers into framebuffers which don't ever have it. We should switch to rendering directly into the main framebuffer anyways. It should be faster.
Possible solutions:
A) expose antialias Map option
Expose an antialias option for Map that creates contexts with antialiasing when possible. This is the easiest change but it also don't fix the problem by default and it doesn't fix antialiasing for building layers.
B) request antialias by default
We should measure the performance costs of this so that we aren't making our maps slower if we don't need to. We would also need to check if this regresses our rendering (I think it should be ok).
C) request antialias when we have buildings or custom layers
The problem here is that we can't know if a building or custom layer will be added in the future. We could decide based on the initial style. Or we could request a new one if one of these layers is added, but that could be hard to do seamlessly.
D) provide other antialiasing for custom layers
We could provide FXAA (or something like it) for custom layers but I think this isn't what people expect and it could be more expensive.
The text was updated successfully, but these errors were encountered:
mapbox-gl-js version: 0.51 / master
browser: all
Steps to Trigger Behavior
/debug/threejs.html
Link to Demonstration
yarn start-debug
http://localhost:9966/debug/threejs.html
Expected Behavior
Antialiased rendering.
Actual Behavior
mapbox-gl doesn't use browser provided antialiasing. Instead we antialias layers ourselves by blurring edges, etc. We haven't revisited this decision recently. I think the original reasons for not using browser provided antialiasing were maybe:
Since we are not requesting antialiased contexts custom layers don't have access to browser-provided antialiasing.
Even if we were creating contexts with antialiasing, we currently render custom layers into framebuffers which don't ever have it. We should switch to rendering directly into the main framebuffer anyways. It should be faster.
Possible solutions:
A) expose
antialias
Map optionExpose an
antialias
option forMap
that creates contexts with antialiasing when possible. This is the easiest change but it also don't fix the problem by default and it doesn't fix antialiasing for building layers.B) request
antialias
by defaultWe should measure the performance costs of this so that we aren't making our maps slower if we don't need to. We would also need to check if this regresses our rendering (I think it should be ok).
C) request
antialias
when we have buildings or custom layersThe problem here is that we can't know if a building or custom layer will be added in the future. We could decide based on the initial style. Or we could request a new one if one of these layers is added, but that could be hard to do seamlessly.
D) provide other antialiasing for custom layers
We could provide FXAA (or something like it) for custom layers but I think this isn't what people expect and it could be more expensive.
The text was updated successfully, but these errors were encountered: