Add options for bounding and scaling the rendering canvas

[TheOneric]

Cleaned and simplified (keeping the same results for positive saling values) version of #119 backporting a jellyfin feature.
( @dmitrylyzo )

In particular I'd like to get some feedback on the name for the option added in the second commit: While I find hardHeightLimit to be an ok name, I was also considering canvasHeightLimit, maxCanvasHeight and maxRenderingHeight but I'm not sure if eg the canvas-names might cause confusion with the HTML-<canvas> element.

Another previously discussed topic was if I'd be better to bundle the prescale options into one object internally or also externally. I have no particular preference with regards to that.

[TFSThiagoBR98]

In particular I'd like to get some feedback on the name for the option added in the second commit: While I find hardHeightLimit to be an ok name, I was also considering canvasHeightLimit, maxCanvasHeight and maxRenderingHeight but I'm not sure if eg the canvas-names might cause confusion with the HTML-<canvas> element.

To me maxCanvasHeight or maxRenderingHeight looks good, I don't see any problems using canvas names as it uses canvas element for rendering, so I'll leave it up to you to decide the final name.

[TheOneric]

I don't see any problems using canvas names as it uses canvas element for rendering

I was thinking of possible confusion with the CSS height property of the HTML <canvas> being rendered on. Not sure how likely/problematic this is though.
For now I renmaed the property to maxRenderHeight.

[TFSThiagoBR98]

LGTM

[TheOneric]

@dmitrylyzo: I don't think I changed any functionality jellyfin relies on during cleanup, but just to make sure could you take a look?

[dmitrylyzo]

Probably the only thing left is a true noop (skipping multiplications) when scaleFactor is 1.0. But since this function is rarely used, noop doesn't make much sense.

Should we round the result (to pixels)?

[TheOneric]

the only thing left is a true noop (skipping multiplications) when scaleFactor is 1.0.

1.0 already is a “true” noop. Afaict for all IEEE-754 compliant floating point implementations, if a represents a real number, then a * 1.0 === a and if a is additionally non-zero a / a === 1.0.
Meaning if scalefactor === 1.0 the passed width and height values will be returned unchanged — a noop.

[dmitrylyzo]

1.0 already is a “true” noop. Afaict for all IEEE-754 compliant floating point implementations, if a represents a real number, then a * 1.0 === a and if a is additionally non-zero a / a === 1.0. Meaning if scalefactor === 1.0 the passed width and height values will be returned unchanged — a noop.

I meant that all this math will be applied even with scalefactor === 1.0, but could be omitted ("true noop").
But...

since this function is rarely used, noop doesn't make much sense.

[TheOneric]

Yeah, _computeCanvas is already lightweight and only runs on resizes and init, so there's no real performance benefit to adding another branch to skip the remaining code.

[ThaUnknown]

@dmitrylyzo @TheOneric are there any more JS PR's to merge which aren't already made? If not I could start work on v2 and have it finished by the end of the week.

[TheOneric]

are there any more JS PR's to merge which aren't already made?

yes.

[ThaUnknown]

are there any more JS PR's to merge which aren't already made?

yes.

sorry, i meant from the original pr Dimitry made, any chance you could abridge me what those are?

[TheOneric]

from the original pr Dimitry made [i.e. pr#111], any chance you could abridge me what those are?

Excluding this PR there is:

Merged:

• fix handling of empty ASS_Images

Created but not final or not reviewed::

• conditionally redirect C++ output for nicer display in the browser console
• Refactor buffer struct into C++-class
  • additionally: fixing newly found overflow bugs

Uncreated:

• drop animations feature
• renderAhead
  • additionally: improvements to renderAhead to never be worse than wasm-blend (the state in PR#111 is worse when falling behind schedule)

[ThaUnknown]

• additionally: improvements to renderAhead to never be worse than wasm-blend (the state in PR#111 is worse when falling behind schedule)

Here's what I think:

• drop animations feature: this is really good for a lot of low-end devices and has good applications, so we should do it
• renderAhead: imho this idea is fundamentally flawed, it should render ahead/buffer measured in time, rather than memory, I plan on creating something like this, additionally some of its components like 'renderOnDemand' arent exactly what they describe, and I plan on creating a renderOnDemand mode

Additionally, ideas which aren't posted here:

• font improvements: JS & C++: I didn't understand their point in all honesty, but I didn't have to work with massive font files, so there might be valid reason for them
• onDemandRender: JS: render subtitles as the video player is presenting video frames using requestVideoFrameCallback, chromium only [currently working on this], this allows us to omit all video events, pausing states, etc. additionally its async so if the video decoder drops frames, it wont ask to render subtitles
• offscreenRender: JS: handling rendering 100% in the worker, chromium only, firefox support soon:tm:
• C++ decode: the entire code for decoding bitmaps NEEDS to be in C++ rather than JS, blendrender already creates the bitmaps in C++, but it additionally blends them, I'd like an options for C++ to create multiple bitmaps without blending them, rather than creating 1 blended bitmap TLDR moving this code to C++
• render modifiers [offscreen, async, ondemand], currently you cant use both blendrender and lossy render at once, even tho you could, i plan on adding "render modifiers" options, which will allow you to mix and match, the 2 base """render modes'"" would then be JS blend and WASM blend

requestVideoFrameCallback can potentially allow us to do frame-perfect painting of subtitles if renderahead is done with time, rather than memory.

[TheOneric]

@ThaUnknown: this PR is about prescaling and bounding the canvas and not the right place for extended discussion of general ideas/feature requests for the future.