PanZoomWithCover does not cover its container on zoom out
HighLiuk opened this issue · comments
Hello again @sasza2,
you're on fire these days! Please go on like that!
While you still fix a lot of bugs and implement a lot of features, I'm here to show you one more bug I found.
This one here is for the PanZoomWithCover component.
As you can see, if I zoom in on the bottom right corner of the background and then zoom out on the upper left corner, the image shrinks.
I am not sure if this was intended or not, but PanZoomWithCover should cover its container even during zoom out.
I assume this is a bug since after the zoom reaches its minimum value, the image stretches to cover (though with transition).
Also (not shown in the gif but you can try reproduce it), after you zoom out and the image is very small, if you click on the image and then you move the mouse, the image suddenly stretches to cover, without transition (unfortunately I did not rec that on the gif, but you can try reproducing it).
okay, thanks. I know where the problem is here and in #61 but I need some more time to fix this
Hi @HighLiuk, could you check if this issue is still occurring at https://github.com/sasza2/react-panzoom/tree/bugfix/zoom-boundary-issue ?
Hi there @sasza2. Both this issue and #61 seem fixed in a row.
Though I've noticed a few things:
- zooming is very slow, meaning each time I wheel in or out the zoom is very very slow (but I assume this is related to some prop I pass to the PanZoom components...
- so the obvious way for a user to solve this is to rapidly zoom in, leading us to one more issue... it's like wheeling is debounced, probably for performance... could be since
ZOOM_DESKTOP_THROTTLE_DELAYtripled from 100 to 310... I guess 310 is too much - I experience the same 310 delay even when pinching with the touchpad on my laptop, which leads me thinking that the mere distinction between desktop and mobile is not enough since you can zoom by pinching or by wheeling on desktop
So I was wondering... shouldn't the library consumer be able to configure the values in the consts file as they wish? Or do you think it's your responsibility to choose the absolute right values?
Nevertheless, I guess both issues are solved, though they rise new questions. What do you think about?
Thanks for checking branch, i'm really glad that both issues are fixed.
So I was wondering... shouldn't the library consumer be able to configure the values in the consts file as they wish? Or do you think it's your responsibility to choose the absolute right values?
Personally I think it's library responsibility to set default values. It would be too hard for newcomers to figure out right values for zoom speed. They would probably give up on library.
(but I assume this is related to some prop I pass to the PanZoom components...
There's already a prop zoomSpeed - it defines how fast zoom value increases / decreases. maybe it should be connected with zoom throttle time and not zoom value, hm.
zooming is very slow, meaning each time I wheel in or out the zoom is very very slow
You're right, now zooming on desktop is a little bit slow. did you try changing value of const ZOOM_ANIMATION_DELAY to 100ms? For me 100ms is okay, what do you think?
I'll check them as soon as I can.
One more thing I've noticed is that zooming in and then out is not the same, but this is not a new issue, and it's probably a separate issue.
I'll try explaining it better tonight.
Hey @sasza2 sorry for the delay of the response.
If I change ZOOM_ANIMATION_DELAY to 100 I can see the duration of the animation very fast, whilst if I put it to 500 the duration of the animation is slower. So it looks like ZOOM_ANIMATION_DELAY is rather a "zoom animation duration". I would not change this to 100 since otherwise the animation is not smooth.
On the other hand, it looks like if I lower ZOOM_DESKTOP_THROTTLE_DELAY the issue is solved, in the sense that I am allowed to zoom fast without having the feeling of losing some wheeling.
Thus I think that ZOOM_DESKTOP_THROTTLE_DELAY should be kept low, like to 100.
The only missing piece of the puzzle is your comment stating
should be higher than animation delay
which theoretically should be true, since you should wait for the animation to end before accepting a new zoom event to occur. But in practice, it either gives a bug or a non-smooth animation.
Did you encounter any unwanted behaviour if you allow ZOOM_DESKTOP_THROTTLE_DELAY < ZOOM_ANIMATION_DELAY?
@sasza2 thanks for pointing out the zoomSpeed prop. It is accepted and it solves the problem, though Intellisense does not suggest it (try it yourself in the Cover.stories.js example).
This is curious since the PanZoomWithCover props should be of type PanZoomWithCoverProps which includes PanZoomCommon, which in turn includes zoomSpeed.
May this have something to do with the forwardRef signature?
@sasza2 for the last problem I've pointed out
One more thing I've noticed is that zooming in and then out is not the same, but this is not a new issue, and it's probably a separate issue.
just forget about it, I've tried to reproduce it but it's working fine now.
ok, I updated branch https://github.com/sasza2/react-panzoom/tree/bugfix/zoom-boundary-issue and completely removed ZOOM_ANIMATION_DELAY with couple changes. Could you take a look and say what you think?
Thanks @sasza2,
however now the animation on zoom does not work anymore.
And indeed I see you've removed the animation from useZoom.ts. How come?
@HighLiuk I removed zoom animation for now. I think we should create another issue for it and rethink how to implement it to be smooth, because its more complicated thing. what do you think?
Yeah I've tried dealing with it all the evening and I see it's a bit frustrating.
Let's bring the discussion to a separate thread