When I use dooble it takes minutes to scroll, I only have this with 2 laptops. I don't have this problem on my desktop comp. Even if I have to fill something out, it takes minutes.
I have (or had) this problem. Answer these questions to see if we have the same issue:
1) Are these machines able to emit a beep? Not a sound through the soundcard but a tone through the speaker or transducer on the mobo. If yes, it's a different problem.
2) After scrolling and finding that nothing happens, does moving the mouse around _a lot_ over the window cause the accumulated scroll actions to happen all at once?
3) Assuming you're running AOS, run 'ACPISTAT | MORE'. At the top is a list or IRQs and the number of times they've been triggered. Is the count for IRQ 0 very low (in hundreds or less) or is IRQ 0 simply missing (either of these may be true)?
If the answer to (1) is no but (2) and (3) are yes, then we have the same problem: the clock which feeds the 8254 timer circuit has been gated off.
The 8254 has 3 timers: one is used to make sound while another is used by many apps such as Dooble as a "high-resolution timer". To use it, the app sets a counter to the number of milliseconds required. Each clock pulse then causes it to decrement that counter. When that counter reaches 0, it issues an IRQ 0.
If the clock signal has been turned off, the counter never decrements, the IRQ is never triggered, and Dooble fails to scroll. There is one oddity here: for unknown reasons, significant USB activity (or at least, USB mouse activity) will trigger an IRQ 0. That's why moving the mouse may cause scrolling - it mimics the timer going off.
I spent a huge amount of time identifying the nature of the problem but never came up with a solution, only a work-around. The high-res timer can only be used by one app at a time. If it's busy, the app has to fall back to one of the system's conventional timers. So, I wrote a little util that claims the HRT for as long as possible to force Dooble and other stuff to use an alternate timer. This works fine for scrolling but multimedia performance is terrible - VLC is unusable.
AFAICT, only a firmware update would fix the problem - and that's unlikely because MS stopped using the 8254 in Win 7 or 8. Consequently there's no way to demonstrate to some Tech Support droid running Win 11 that there even is a problem.
So I seem to be running into this problem, on ArcaOS 5.1.1 using the latest version of Dooble/Qt5 (2024.12.31). Scrolling is indeed pretty much impossible, and it seems I match the criteria in the quoted post. Somehow, I find it hard to believe the cause is something as arcane as the 8254 timer controlling Dooble's scrolling of all things, but I'm no programmer or expert, so perhaps it's the real cause.
Is there really nothing else that could be the cause here? Everything else is working great, there's no CPU usage spike or anything like that when scrolling, and everything else runs and works fine. Why is it only Dooble - as far as I can tell - that suffers from this? Without Dooble, there doesn't seem to be a modern browser for ArcaOS, and that really limits my ability to use it, which makes me sad.