Hi @coldays and thanks for the PR.
Sorry didn't have time to review this and include it in the new version.
From a quick look the half width/height does not work properly when you zoom in/out.
Generally, I agree but don't restrict the user much. Maybe 5% should be the limits or something.

Hey @SuRGeoNix!
No worries! I'm in no hurry

From a quick look the half width/height does not work properly when you zoom in/out.

It seems to me to work exactly as works in the master branch. Can you give me some repro steps? I'll look into it and fix it

Generally, I agree but don't restrict the user much. Maybe 5% should be the limits or something.

I'm not sure I see the point of panning 95% outside of the video frame, but you probably know some use cases I'm not familiar with. Maybe we can make the amount configurable?

@coldays I use the FlyeafPlayer sample and unzoom (mouse wheel down) and then trying to pan move (ctrl + mouse drag) left/right (50% will not work in this case)

Other reason I concern is that the zoom will not work properly based on mouse center in these cases (but I didn't review this much)

@SuRGeoNix It seems to me to be working as intended?

I'm not sure I understand what you mean. Are you thinking about that I've added a "zoom and pan reset" when you zoom out to less than 100%? If I remove this change, it still seems to work fine:

My mistake, I didn't realize that it was on purpose. I thought the 50% was general not only for the current/0 zoom.
This helps to prevent losing the pan out of the visible area but at the same time restricts the user's freedom (too much).
I think it's easier (e.g. to press 0) for resetting when losing it rather than restricting pan move.

I've seen issues e.g. with too much Zoom in/out that I will try to include in the next update. I'm up to discuss of how much we should restrict the pan movement though.

This is a fairly common way of restricting panning for players that offers panning and zooming, but I do understand your concern.
We could make the amount allowed off screen configurable.
We could also make the constriction configurable on/off, maybe something like "Constrict panning" and "Reset pan and zoom on either hotkey or zooming out"?

@SuRGeoNix what do you think? Should we introduce a config for this? I can remove the "reset pan and zoom" part if that's what you don't like

@coldays Had a quick look again...

1. Still has issues (I spot at least one with rotation)
2. I don't understand why restricting zoom out, if you really want it it must be in config and not by default
3. I don't understand why restricting pan move that much, if you really want it it must be in config and not by default
4. (Note) SetViewport should be considered as hot path. Which means it shouldn't have performance penalties to support this.

@SuRGeoNix I tested with rotation now, but I couldn't spot any issues. Can you tell me what issue you spotted?

When it comes to the restriction, it's because I believe it gives a better user experience. I'm more than happy with having them behind a config and being turned off by default. I've pushed a change where I've introduced this in the player config.

I agree SetViewport is a hot path and should be kept as performant as possible. Please tell me if you think the current code does not meet that requirement.

@coldays Let's see this from different point of view...

PanXOffset/PanYOffset/Zoom (possible also Rotation/Ratio and the new Crop that I've added) are specific for the current input and probably should be reset when you open a new input automatically. In this case, we should consider to do the validations during the set of those variables (based on percentages comparing with the renderer's current Viewport dimensions) instead of renderer's SetViewport. There is no need also to reset them during validation failure, only prevent to set the value instead.

Another possible problem is that currently the PanXOffset/PanYOffset/Crop work with original image size and not percentages(?).

@SuRGeoNix I agree! When I started making this, I started doing it in the Set methods, but ended up moving it to SetViewport because it already had all everything I needed pre-calculated. I can move it back to the Set methods.

Hmm, I'm not sure it would be a problem for this feature, but it would be a lot easier if they were percentages. I think it would be better in the long run to use percentages, like in the scenario where a video stream changes resolution, but not aspect ratio, the PanOffset would remain correct.

@SuRGeoNix I've looked at putting the constriction of pan x/y into the SetPan methods, however, it is possible to pan the video by zooming without these SetPan method ever getting invoked. If we do the validation in SetViewport however, this is not possible and the user is never able to have the video outside of the set boundary. Do you still want me to move the validation out of SetViewport?

Changing the pan values to be percentages might solve this problem.

When you change each of those parameters you should calculate the position of the new viewport (with the same code that it exists in the SetViewport) and ensure that it will be in a valid position. I will look in to it...
The problem is when you resize the window it needs to re-calculate this (if we don't use percentages) and not even sure if it is invalid during resize what it should do.

Yeah that's true. We also need to make sure that we don't do all of these calculations unnecessary amount of times while panning and zooming.
Maybe we could extract the code in SetViewport so that we get the new viewport in the other set functions.

It also sounds to me that changing to percentages would be the best course of action at some point, but that is a breaking change