Remove log spam when quickly resizing the viewer

[Wumpf]

What

• Fixes Error when quickly resizing viewer with 3D view #4455

Got a good repro of this on my windows machine by using the screenshot action on a low-dpi screen (screenshot action will do a quick resize on native) while having the pose tracking example open.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[emilk]

So the viewport coming from egui was somehow wrong?
Is this a bug in an egui crate?

[Wumpf]

we only passed on the viewport offset from egui, not the viewport size. We then assumed the size was what we had previously on the viewbuilder and set a new viewport accordingly. In rare cases it turned out that this size + the offset from egui caused us to set an invalid viewport (after egui already set a correct one).

... which come to think means that the viewbuilder got an outdated size! This is concerning but I reckon this can easily happen though when new sizes come in asynchronously; to nail this down perfectly we'd need to know when egui queries the size that leads to the final renderpass.
This PR instead just trusts egui with the viewport setting, after all egui also set up the renderpass and knows what a valid viewport is for that renderpass.