Reconsider default maxCanvasWidth and maxCanvasHeight values

[mrxz]

Description:
By default the renderer resolution is capped at 1920x1920. This was introduced back in 2018 with #3641. There are a couple of downsides to this:

• Screen resolutions have gone up, making it likely that this cap is hit in everyday configurations
• Exceeding the cap might go unnoticed, or the resulting blurriness can be difficult to attribute to this cap
• The width and height take devicePixelRatio into account, which is inconsistent with Three.js ("device pixels" vs "CSS pixels")

I would propose changing the default values to -1 making it uncapped by default. Users can always opt-in to capping the size if they have a specific need for it.
Otherwise it wouldn't hurt log a warning in the console once the cap is exceeded and possible increase the default cap.

• A-Frame Version: 1.5.0
• Platform / Device: all

[dmarcos]

Yeah we can revisit the values. In general not super fan of using -1 values to indicate no value. Wonder if it makes sense to keep the limit at all. I personally don't use it and even forgot that it exist :)

[mrxz]

Well, only suggesting -1 since that's already how it works (docs):

aframe/src/core/scene/a-scene.js

Line 783 in 17f06f6

if (!maxSize || (maxSize.width === -1 && maxSize.height === -1)) {

Personally I think the limit can be removed entirely. Most people probably don't expect this cap and only learn about it when they or one of their users runs into it. Not to mention that it conflates the canvas size with the render resolution. It's a lot cleaner to have the size be the canvas element size in CSS pixels and use the pixelRatio to adjust the effective render resolutions. That's how I see it done in a lot of Three.js apps nowadays.

That also makes it easier in case users do want to limit it. They can either limit the actual canvas size (when 'embedded') or adjust the renderer's pixelRatio.

If agreed I can create a PR that removes the logic (thus changing the default to not cap the size).