Low physics FPS makes mouse wheel scrolling in GDScript inoperable after restarting the Editor

[lukas-durica]

Godot version:

Godot 3.1

OS/device including version:

NVIDIA GeForce GTX 1070

Issue description:

Higher Physics (tested with 700, but the number may be lower) FPS makes mouse wheel scrolling in GDScript inoperable after restarting the Editor

Steps to reproduce: Create a new project Project Settings > Physics > Common >Physics Fps > 700 Restart the Editor Create new GDScript Move cursor down, so you can scroll the script with the mouse wheel But actually, you can't

Bugsquad edit (keywords for easier searching): mousewheel

[Calinou]

As a workaround, try disabling Text Editor → Open Scripts → Smooth Scrolling in the Editor Settings.

[jamie-pate]

This also affects OSX trackpads with normal Physics FPS speed? You need to swipe really fast for scrolling to work, I suspect it's rounding the delta values down to 0.

Related? #28369

[Calinou]

I can't reproduce this on 4.0.beta12 (Linux, using standard mouse wheel and 100% editor scale).

Physics FPS (now Physics Ticks per Second in the advanced Project Settings) does affect mouse wheel scrolling smoothness, but it still works when set to 240 or even 1000.

I can still reproduce this on 3.5.1, but only with Physics FPS set to 1000. Scrolling still works correctly with Physics FPS set to 240, which is likely the highest practical value you'll use in a real world project.

[Zireael07]

@Calinou Can physics fps be limited to 300 or so to prevent people setting humongous values (I dimly recall some other things breaking with values like 800 or 1000)

[reduz]

I can't reproduce either.

[Calinou]

@Calinou Can physics fps be limited to 300 or so to prevent people setting humongous values (I dimly recall some other things breaking with values like 800 or 1000)

Very high physics FPS values can make sense for simulation racing games (fast cars need high physics FPS to remain stable), but I agree there's little reason in going past 300, even for most simulation racing games.

Regarding things breaking with very high values, this can be resolved in 4.0 now that https://github.com/godotengine/godot-proposals/issues/1893 is implemented there (it can be redone for 3.x too).

[KoBeWi]

Also can't reproduce.

[Calinou]

Reopening, as I can reproduce this with lower physics ticks per second values (such as 1) in 4.2.dev6.

The underlying cause is the same as the previous issue with high physics FPS. Smooth scrolling shouldn't occur on physics step, but on process step (formerly idle step). This will also make it look smoother on high refresh rate monitors.

[DJKero]

@Calinou Can physics fps be limited to 300 or so to prevent people setting humongous values (I dimly recall some other things breaking with values like 800 or 1000)

Very high physics FPS values can make sense for simulation racing games (fast cars need high physics FPS to remain stable), but I agree there's little reason in going past 300, even for most simulation racing games.

Regarding things breaking with very high values, this can be resolved in 4.0 now that godotengine/godot-proposals#1893 is implemented there (it can be redone for 3.x too).

It depends on the type of game and the requirements of the project, but 1000hz can be nice to have so putting a hard cap before 1000 could be cumbersome for some projects in my opinion.

[Calinou]

It depends on the type of game and the requirements of the project, but 1000hz can be nice to have so putting a hard cap before 1000 could be cumbersome for some projects in my opinion.

Godot can't clamp the mouse polling rate - it's decided by the OS. Also, I wasn't referring to dropping the polling rate below 1,000 Hz, but rather dropping it from a value above 1,000 Hz back to 1,000 Hz. Some modern mice can go up to 8,000 Hz, which uses a lot of CPU for little benefit (unless your display is 360 Hz or more). The sweet spot for 240 Hz display users is typically 2,000 Hz for instance, as this does reduce jitter measurably compared to 1,000 Hz on those displays.

[DJKero]

The sweet spot for 240 Hz display users is typically 2,000 Hz for instance, as this does reduce jitter measurably compared to 1,000 Hz on those displays.

Oh I didn't knew about that, it's good to know, do you have any resource that talks about the topic? About this issue it is exactly what I was experiencing with my project, I did change the physics fps to default and restarted the editor and it works smoothly.

The underlying cause is the same as the previous issue with high physics FPS. Smooth scrolling shouldn't occur on physics step, but on process step (formerly idle step). This will also make it look smoother on high refresh rate monitors.

Is this happening in scene/gui/scroll_bar.cpp?

[Calinou]

Oh I didn't knew about that, it's good to know, do you have any resource that talks about the topic?

BlurBusters has extensively researched this topic: https://forums.blurbusters.com/viewtopic.php?f=7&t=9785

Is this happening in scene/gui/scroll_bar.cpp?

Smooth scrolling is implemented in TextEdit (scene/gui/text_edit.cpp) which relies on ScrollBar. However, ScrollBar's implementation isn't exposed to scripting, so the only way to use it is currently in TextEdit.

[lostminds]

I just ran into this on 4.3rc1 as well.

Seems like the issue could be here in void ScrollBar::_notification(int p_what): https://github.com/godotengine/godot/blob/607b230ffe120b2757c56bd3d52a7a0d4e502cfe/scene/gui/scroll_bar.cpp#L327-L346

Where it's doing the scroll smooth animation on physics process notification instead of NOTIFICATION_DRAW. For the scrolling it looks quite straight-forward to just move that code into the NOTIFICATION_DRAW part, use regular process delta and no longer turn physics processing on/off.

[Calinou]

For the scrolling it looks quite straight-forward to just move that code into the NOTIFICATION_DRAW part, use regular process delta and no longer turn physics processing on/off.

Last time I tried that, it didn't work correctly. (Also, I think NOTIFICATION_PROCESS would be more suited here.)

[lostminds]

Last time I tried that, it didn't work correctly. (Also, I think NOTIFICATION_PROCESS would be more suited here.)

Yes, I agree that NOTIFICATION_PROCESS would be a more appropriate for animating the scroll. However, if this was what didn't work when you tried it, could it be that perhaps the scroll bar is not getting these process calls, maybe due to processing mode being disabled? This could also explain the curious current workaround of enabling physics_processing when scrolling or dragging starts and then disabling it again when it ends. If the scroll bar was getting normal processing notifications this would seem superfluous.