Add support for backing framebuffer object with renderbuffer

[levinli303]

Most likely viewport effects do not need to read from depth attachment so we can use render buffers when available.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[375gnu]

let me have some time to check this

[375gnu]

@levinli303 do you have any numbers to show benefit?

[levinli303]

@levinli303 do you have any numbers to show benefit?

I got time to test today, and sadly it seems to consistently and negatively impact the render time at least on iPad (to switch depth attachment from texture to renderbuffer in viewport effect)

For the demo script, the average frame time (without viewport effect) is around 6.45ms the average frame time (with viewport effect renderbuffer as depth attachment) is around 6.57ms the average frame time (with viewport effect texture as depth attachment) is around 6.5ms

[levinli303]

but in terms of memory usage after booting up:

no viewport effect: 522.3M viewport effect renderbuffer as depth attachment: 525.8M viewport effect texture as depth attachment: 558.8M

it seems a good win to switch to render buffer.

[375gnu]

What resolution your ipad has?

[levinli303]

What resolution your ipad has?

2388 x 1668.

[375gnu]

What resolution your ipad has?

2388 x 1668.

The it should use 15MB less, not 30. Am I correct?

[levinli303]

The it should use 15MB less, not 30. Am I correct?

my bad. it seems GL_DEPTH_COMPONENT24 should be used instead of GL_DEPTH_COMPONENT in glRenderbufferStorage. and in my previous test, glCheckFramebufferStatus has been returning GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT thus the framebuffer is not really used for viewport effect.

After correcting this, the memory usage and render time of the two were negligible.