Fix puck rendering behavior Android

[alasram]

The puck is typically rendered last and while its VAO is bound command that change the VAO are executed causing glitches. I didn't debug what commands are affecting the VAO but as a workaround the VAO is unbound after drawing which ensures the state of a Drawable object remains clean without adding overhead. This works around #2879

[github-actions]

Bloaty Results (iOS) 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [ = ]       0  [ = ]       0    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results-ios/pr-2957-compared-to-main.txt

[github-actions]

Bloaty Results 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%    +144  +0.0%     +96    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results/pr-2957-compared-to-main.txt

Compared to d387090 (legacy)

    FILE SIZE        VM SIZE    
 --------------  -------------- 
   +28% +32.4Mi  +426% +25.4Mi    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results/pr-2957-compared-to-legacy.txt

[github-actions]

Benchmark Results ⚡

Benchmark                                                     Time             CPU      Time Old      Time New       CPU Old       CPU New
------------------------------------------------------------------------------------------------------------------------------------------
OVERALL_GEOMEAN                                            -0.0064         -0.0060             0             0             0             0

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/benchmark-results/pr-2957-compared-to-main.txt

[TimSylvester]

Curious, I don't think that should be necessary. Doesn't it mean that either those commands shouldn't be happening at all, or that they are happening with the wrong bindings?

[louwers]

Android render test timing out is just because we were running benchmarks, should restart...

[alasram]

@TimSylvester I haven't really debug this. I only noticed in renderdoc that the buffers bound to the VAO change when the glitch happens. This means that while the puck VAO is bound (It's the last drawable in the frame), and before the next frame's drawable, there are calls that bind buffers such as glBindBuffer(GL_ELEMENT_ARRAY_BUFFER)

[louwers]

@TimSylvester Since we have multiple people that report this is an issue, do you think this is an acceptable work-around?

[adrian-cojocaru]

I haven't been able to reproduce the glitch, but from what @alasram described a single glBindVertexArray(0) at the end of the frame (context::endFrame) should block any further updates to the puck's VAO.

[alasram]

This is a legit fix.
After puck rendering, the upload pass might create or update index buffers. This can lead to issues with VAO bindings, as the newly created/updated buffers are bound to GL_ELEMENT_ARRAY_BUFFER without considering the active VAO: calls to UploadPass::createIndexBufferResource or UploadPass::updateIndexBufferResource
This PR is enough to address the issue. An alternative approach, though less conservative, is to unbind the VAO at the start of the upload pass (reducing GL calls). Unless there's evidence of performance benefits with VAOs in a specific implementation, the simpler approach is bind a dummy VAO when a context is created and bind vertex buffers directly for each drawable.
I recommend merging this PR as it provides a straightforward solution to a real bug.

[TimSylvester]

Sorry, I was out since 10/30. Something must be making GL calls without binding its own buffer first but if it's not leading to an observed bug, I guess it's not a big deal.