Add config to enable/disable mipmaps for raster layers. #1853
Conversation
|
Bundle size report: Size Change: +131 B
ℹ️ View Details
|
…o raster-mipmap-config
|
If this is something that should be done similarly in native and should be respected there as well I would consider using a style spec property for raster layer, I think, I'm not sure... |
|
@HarelM, is there someone we can pull into the request that can comment on the rendering aspect of this change? I think using the style (and having a corresponding implementation in native) is a more involved approach but certainly doable. For that, I would suggest adding a boolean style property to the raster source that configures whether it generates mip maps or not. (With that approach, the internal changes to the Texture class would still look the same.) |
|
@JannikGM are you familiar with the mipmap here? Can you take a look at this PR by any chance? |
|
I'm not sure if this PR is beneficial; I don't follow the argument in the PR description.
This is not what mipmapping is for. You must be thinking of anistropic filtering (which is related to mipmapping, but not mipmapping). I'll mention the basics here:
There are more details for each of these techniques and variations in how they can be used. I'd also suggest to look at the images on Wikipedia, as they nicely show these techniques (except that there's no example for zooming on a mipmap and their mipmap example is pretty much a case for anistropic filtering): To me, it looks like mipmapping in maplibre also always enables anistropic filtering (if supported).
There still shouldn't be any noticable overhead with most GL implementations. Mipmap generation is started using From the application perspective, this should be free, only delaying the first frame by a fraction of a millisecond. The only cases where I'd imagine mipmap generation to be problematic are:
So I'd guess that this saves a neglible amount of memory, saves a tiny bit of setup time for each raster tile, but then adds additional cost during rendering while also degrading visual quality. What can be done probably, is to limit mipmap levels to the required ranges (as most tiles are only displayed somewhere between 50% and 200% of their original size; I think?). I did not check if this is already being done. Did you notice any real world performance issues with mipmap generations @kircher1 ? What hardware/software were you running on? Edit
Yes, something like a retro/pixelated look. But maplibre layers typically have edge smoothing and even for a pixel style you'd want edge smoothing in your raster tile to get a more consistent look across different devices. |
|
Re tilting: If the use case of MapLibre is a top-down map that doesn't allow tilt, the effect of mipmap is subtle on raster tiles. Like you say, the raster layer acts like a mipmap itself. A tilted view is the classic use case for mipmaps because texture aliasing is so apparent in oblique views. e.g., wiki entry you linked to on mipmaps: Aniso helps too but mipmaps are primarily the thing that is mitigating the aliasing. Mipmaps and aniso are certainly the right tools to prevent texture aliasing, but if you use MapLibre in a way that doesn't allow tilting the view, then texture aliasing isn't a concern. Re perf benefits: The memory overhead for the mip level limits to 1/3 of the original raw texture size. So, for a 256x256 RGBA tile (256 * 256 * 4 bytes) = 250KB, the additional memory overhead is ~83KB; Load a thousand raster tile textures, that's ~80MB of memory. Probably not going to be the tipping point of an OOM, but also not small. The computation of the mipmap also has overhead, and until recent versions of Chromium this was a CPU side cost, which ate into javascript main thread time and could lead to jankiness: https://chromium-review.googlesource.com/c/angle/angle/+/3406643 Newer versions of Chromium defer the work to the GPU, where it can be done more efficiently. I don't know how other browsers handle it, but in the worst case, 1) you have a map that doesn't benefit from mipmaps, and 2) your user has no GPU acceleration. They pay the cost of generating mips on their CPU, wasting cycles that aren't needed. |
|
Also, there's a visual aspect to this, where having the mips enabled all the time can affect topdown views subtly, making them more blurry in certain zoom levels. I think this is because the GPU starts to sample the second miplevel instead of sticking to the highest miplevel. That is undesired in a page we have. What would be better there, would be a regular linear filter, which is slightly sharper (i.e. we don't need a mipmap) #1828 (reply in thread) |
I wish this was part of the PR description. It provides some good context.
I agree, but mipmapping at oblique angles, while avoiding the aliasing, usually also just leads to a blurry mess (without anistropic filtering). Head-on, mipmaps should always improve visual quality (if configured correctly).
Fair enough.
Yikes! Being from the embedded world, I wasn't aware WebGL implementations were still this poor in this regard.
Let me preface this by saying that I have little experience with raster-tiles in maplibre. But I should add that this also very much depends on the display resolution and underscaling / overscaling of the tiles. Obviously a zoomed out map on a 4k display shouldn't be using a 0/0/0 256x256 raster tile. Mapbox added their optional However, if you have a small 200x200 pixel iframe and a 512x512 raster tile, then you'd benefit from mipmapping.
Can you show an example? I'd be curious about the tile-sizes / display-sizes where this becomes a problem. Also, if this is true, then we might even want to disable mipmap sampling by default until a specified pitch? Consider me convinced: I think it makes sense to allow users to toggle this, at least until we have a smarter solution. My thoughts on this topic so far:
|
|
Renaming a spec property is not an option due to breaking changes and backwards compatibility which we avoid as much as possible. I don't see a reason to break the style for this edge case feature... |
Launch Checklist
This adds a config option to disable or enable mipmaps on raster layers. The default is mipmaps enabled.
For clients that don't gain much from having mipmaps generated (eg clients that don't allow tilting the view), then disabling mipmaps will get rid of any potential overhead from the mip level generation that GL is performing on every raster texture. And there are some subtle visual aspects where not using mip filtered textures could be desirable.
Note, another option for this sort of change is to add a style property to the raster data source which controls if mipmaps are enabled or not, rather than having a global config.
CHANGELOG.mdunder the## mainsection.