Canvases and multisampling

[PSteinhaus]

Ok, this is the most annoying bug for me in ggez currently.
I thought good-web-game just wouldn't have it, but it turns out I was wrong.

In ggez 0.6 trying to create a Canvas with a NumSamples count other than 1 leads to this bug: ggez/ggez#695

If we stick to 1 things work out ok, but as soon as multisampling is activated globally the canvas starts to get drawn slightly blurry. This effect increases with multisampling level.

Now the sad thing is: good-web-game currently has the same bug. To recreate try the 03_drawing example, set multisampling to 16 (uncomment a line in the boilerplate) and press a button to switch between drawing onto the screen directly and drawing onto the offscreen canvas, which is then drawn onto the screen.

drawn directly:

drawn on canvas:

As you can see by looking at the white thing somewhat in the middle (which is drawn using a nearest neighbor filter) no MSAA has been applied when drawing it in the second case. The only reason it looks less jagged (but still wrong) is because the whole canvas was drawn somewhat blurry...

The good news is: This replicates the ggez behavior when using a Canvas with multisample count 1 perfectly, so we might fix it by somehow specifying that the framebuffer supplied by a canvas is supposed to have the same level of multisampling as the application. But, AFAIK, there is currently no feature present in miniquad to achieve this.

[PSteinhaus]

Ok, this has now been (somewhat) fixed in ggez by applying a fragment shader workaround.
But, this workaround doesn't work on GLES and I assume it wouldn't work here either, as GLSL 100 is probably too limited for it. (I'm not sure about this though, would need to check whether "sampler2DMS" is available on GLSL 100 as well).

[ccie18473]

When running the drawing example I see a problem with memory comsumption; the process crashes after a few minutes. Same behavior under Ubuntu or Centos. This seems the buggy memory allocation:

amsoares@ubuntu:drawing$ pmap -x 4964 | grep renderD128 | wc -l # <-- Value increases until it crashes
64488
amsoares@ubuntu:drawing$ pmap -x 4964 | grep renderD128 | wc -l # <-- Already crashing
48439
amsoares@ubuntu:drawing$ pmap -x 4964 | grep renderD128 | wc -l # <-- Process dead
0
amsoares@ubuntu:drawing$

I'm not a developer, I'm just learning Rust and ggez/gwg.

[PSteinhaus]

This is indeed bad, thanks for reporting.

It doesn't have anything to do with canvases and multisampling though. Memory leaks suddenly start emerging in all examples where Meshes, or perhaps even other Drawables are created and then dropped in the drawing loop, meaning there is something wrong with their ressource deallocation... very bad, very annoying. I'll try to look into it soon.