Ctrl+wheel zooming scale in CmapTools should be multiplicative, not additive

Have new ideas for the next release of IHMC CmapTools and IHMC CmapServer?
We welcome your suggestions and we will carefully consider whether to incorporate them into the software.
Post Reply
vesjolovam
Posts: 5
Joined: Tue Nov 07, 2023 3:32 pm

Ctrl+wheel zooming scale in CmapTools should be multiplicative, not additive

Post by vesjolovam »

Consider a 20×20 square. For it to appear 60% of its size, it would have to be scaled down to 60% of its size, i.e. there would have to be a -40% change in the overall scale, and that would be a 12×12 square. For the same 20×20 square to appear 200% of its size, it would have to be scaled up to 200% of its size, i.e. there would have to be a +100% change in the overall scale, and that would be a 40×40 square.

Would the same scaling for the scaled squares be achieved through the same scaling up/down or through the same additive change to the overall scale?

If we take that 60% square and add another -40% scale difference, we would get a 20% scale square, i.e. a 4×4 square. Would that appear 60% of that 60% square?
(1a) 60%×60%=36%, — 60% of the 60% of the original size;
(1b) 4/20=20%, — the scale of the square that is the twice linearly reduced (by 40%) version of the original scale;
(1c) 36%≠20%
Thus, no, it would appear almost half the size of the expected square. In other words, linear scaling down is a lot faster than perceptually expected.

The same goes for the 200% square: adding +100% scale difference, we get a 300% scale square, i.e. a 60×60 square, while:
(2a) 200%×200%=400%, — 200% of the 200% of the original size;
(2b) 60/20=300%;
(2c) 400%≠300%
so the square we get is 3/4 of the expected one. Again, in other words, linear scaling up is significantly slower than perceptually expected.

The case of scaling things down (i.e. the first one) is the zooming out case — you can feel (by holding Ctrl and scrolling down) that it's way too fast, especially when getting to 50% and below. And the case of scaling things up (i.e. the second one) is the zooming in case — it is painstakingly slow, try 200% and above. If we zoom out at a constant rate of 90% (i.e. 100, 90, 81, ..., 35, 31, 28, ...), we should get to 10% in ≈22 steps, not in 9, and if we zoom in at a constant rate of 110% (i.e. 100, 110, 121, ..., 259, 285, 314, ...), we should get to 5000% in ≈41 steps, not in 490. So please change the way scaling is calculated for zooming.
rosiewilsonnsjh
Posts: 1
Joined: Thu Jan 04, 2024 5:24 am

Re: Ctrl+wheel zooming scale in CmapTools should be multiplicative, not additive

Post by rosiewilsonnsjh »

thanks for the info! Connections Game
Mikoals
Posts: 4
Joined: Tue Jan 16, 2024 10:19 pm

Re: Ctrl+wheel zooming scale in CmapTools should be multiplicative, not additive

Post by Mikoals »

It would look nearly half the size of the anticipated square. Put otherwise, the rate of linear scaling down is significantly more than what is initially perceived basket random
boiledikea
Posts: 3
Joined: Sun Dec 17, 2023 8:59 pm

Re: Ctrl+wheel zooming scale in CmapTools should be multiplicative, not additive

Post by boiledikea »

When zooming with the Ctrl key and mouse wheel, many software programs (such as mapping or diagramming tools) zoom in an additive or incremental way by defaultgeometry dash lite. This implies that the zoom level is adjusted by a fixed amount with each mouse wheel scroll.
It seems plausible that CmapTools offers many choices for zooming behavior, such as multiplicative scaling. Instead of adding or removing a set amount with each mouse wheel scroll, multiplicative scaling would indicate that the current zoom level is multiplied or divided by a specific factor.
Post Reply