Yup 133% compares to non-mipmapping. It's not a bad amount of overhead considering it makes the rendering potentially faster and better looking. Having said that, the main purpose of mipmapping is to create pre-scaled versions of the image which will be displayed when you render your image with some kind of scale factor. It isn't going to have any effect when you use SetScale above 1.0 as there is no `bigger` image to tap into. It's only going to have an effect when you shrink your image with SetScale below 1.0, and will only use the mipmap level close to/within the scale of the image. For example if you setscale to 0.5 you will probably begin to see the first mipmap level ie 50% size. It won't use the next one until you set scale to 0.25 etc... so if you aren't scaling down very much, and especially if you aren't scaling down to 50% size or less, they aren't going to help and are a waste of memory. I forget exactly how the texture lookup system uses the mipmap levels - I think it does some kind of cross-reference between the current mipmap image and the next one depending on the scale factor? Also there is anisotropic texture lookup which is somewhat more advanced but better quality, and not a standard blitzmax feature.
Where mipmapping is basically a way of selecting texel colors in the Z direction, ie comparing a further-away image to a nearer image, filtering is a similar process but in the X-Y direction. Filtering doesn't need any mipmaps. It's just a way of looking up texel colors and, if necessary, interpolating between their values to create pretend in-between values. Also it might take several texels and blend them together if you're scaling down - basically a way of doing sub-pixel floating-point coordinate access with interpolation. It doesn't need any extra memory to do it, it's part of the texture lookup functionality. It's basically just some different math.
Where mipmapping is basically a way of selecting texel colors in the Z direction, ie comparing a further-away image to a nearer image, filtering is a similar process but in the X-Y direction. Filtering doesn't need any mipmaps. It's just a way of looking up texel colors and, if necessary, interpolating between their values to create pretend in-between values. Also it might take several texels and blend them together if you're scaling down - basically a way of doing sub-pixel floating-point coordinate access with interpolation. It doesn't need any extra memory to do it, it's part of the texture lookup functionality. It's basically just some different math.