Trilinear edge bleeding

So there is this thing with tiled backgrounds that include transparency. Since they are tiling, the trilinear (and bilinear) filtering methods will cause part of the non-transparent part to bleed onto the transparent part (and vice versa). They were mentioned every now and then and I think that was also the reason why the 1px transparent border was added when cropping in Construct to mitigate that issue.

I sometimes see sprites still do this regardless, but it´s rare. I assume it´s because of the spritesheeting going on, that if the sprite happens to be in an "unlucky" spot and at certain zoom levels it can end up bleeding. Here's an example of a sprite having bleeding. In this case it is scaled down quite a bit (used as a more distant object). Looking at the spritesheet it´s quite obvious what causes the bleed. Note that both sprites have the 1px extra border.

One thing I noticed it that the lines will not appear if the game is at the intended zoom level. But once you zoom, scale the game (by scaling the window) or scaling the layout/layer with events, the lines will start creeping in. After some testing I noticed that zooming in is less of a problem, and an additional 1px added will prevent the lines from appearing. When zooming out, even with 2 or 3 pixels extra it will eventually bleed, though you really have to zoom out quite a bit for that.

I just think this shouldn´t be a thing, and I know that setting sampling to nearest completely solves this, but I like my smooth edges, I don´t want jaggies. There must be a way to get rid of this... please :V

Found this info on disabling mipmapping or using texture arrays, sounds kinda promising if possible. Especially the mipmapping since different zoom levels seem to be the main cause of that issue.

gamedev.stackexchange.com/questions/46963/how-to-avoid-texture-bleeding-in-a-texture-atlas

These are two slightly different cases:

1) With Tiled Backgrounds and fractional rendering and linear sampling, the opposite edge of the image can wrap around to a transparent edge, creating a seam. Adding a line of transparency along the opaque edge of the image usually fixes this.

2) With images rendered from spritesheets which are downscaled a lot, there can be bleed from the mipmap. This is an inherent problem with any tool that uses spritesheets and mipmaps: the smaller the mipmap, the more content tends to bleed in to other images. Think of the 2x2px mipmap, where essentially each entire quarter of the spritesheet has become a single color, representing a combination of all the images in that entire quarter of the spritesheet. That happens but to a lesser extent with higher mipmap levels. This is why Construct lets you choose high quality downscaling mode: it pads every image on the spritesheet to a power-of-two size, ensuring it can be resized much smaller before any mipmap bleed happens - but comes at the cost of increasing the memory usage, as all images have to be padded.

Well thanks, the high quality downscale mostly clears it up on the sprites (looking at the spritesheets it´s obvious why). I still noticed bleeding on tiled backgrounds, despite adding padding pixels on the opaque edge even when the game wasn´t all that scaled down. Eventually I settled for 5 extra pixels. Bleeding still happens when the game is scaled down really small, but at that point it´s unplayable anyway.

Guess it´s a quirk that needs getting used to. Thanks again.