Hyperion Entertainment Message Boards

@Deniil

have LimpidClock. It runs at pri -20. Increasing (not decreasing) LimpidClock's priority to *above* the CPU heavy task almost removes all stuttering!!!
I have a theory:
LimpidClock has a 1 second timer. It wants to run once a sec. Once in a while (when the CPU heavy waits for disk I/O perhaps) it gets to run for a brief moment, long enough to start a graphics operation and lock the system draw semaphore. Then it doesn't get to run again until the next second. During this second the CPU heavy task runs and the system, including mouse and keyboard are frozen.

I don't know what may have chnaged, but if that is remotely the case the Limpid design clock is very broken, you should not hold such drawing locks for an extended period. I'd guess it would be a calle to p96LockBitmap() or somesuch. I know from experimentation with SRec src that hold that lock even for very short periods can cause the mouse to appear to jitter slightly.

Solution is simple remove broken sftware like limpidlcok from your system.

broadblues wrote:@Deniil

have LimpidClock. It runs at pri -20. Increasing (not decreasing) LimpidClock's priority to *above* the CPU heavy task almost removes all stuttering!!!
I have a theory:
LimpidClock has a 1 second timer. It wants to run once a sec. Once in a while (when the CPU heavy waits for disk I/O perhaps) it gets to run for a brief moment, long enough to start a graphics operation and lock the system draw semaphore. Then it doesn't get to run again until the next second. During this second the CPU heavy task runs and the system, including mouse and keyboard are frozen.

I don't know what may have chnaged, but if that is remotely the case the Limpid design clock is very broken, you should not hold such drawing locks for an extended period. I'd guess it would be a calle to p96LockBitmap() or somesuch. I know from experimentation with SRec src that hold that lock even for very short periods can cause the mouse to appear to jitter slightly.

Solution is simple remove broken sftware like limpidlcok from your system.

I have also experienced this unexplained jerky mouse movements in my X1000 system, especially when editing my program with CodeBench and maybe Odyssey active. In some other thread Odyssey was suspected to be the reason. Now I do have both these programs active but LimpidClock disabled and it seems to work better. However, LimpidClock is one of my favourite little programs. Maybe Thomas could give it an update if it is really the reason?

Marko

@Broadblues

Solution is simple remove broken sftware like limpidlcok from your system.

But these "broken" softwares worked well under 4.1.6. Why FE broke the compatibility with these not very old programs ?

Me too, i encounter boring jerky mouse lock using CodeBench or Odyssey. I think that it's because I use CentaurZ Photoframe docky but no hope to see it updated...

well, thomas is reading here so he would be the correct person to ask what or if smth is broken with limpidclock.
so if smth is wrong he maybe simply could fix it?

regards...
michael

I would say that holding a system critical lock while running at as low a priority at -20 is not maybe such a great idea after all. At least not with the simplistic scheduler that AmigaOS has been using since version 1.0.

Using any priority less than 0 guarantees that any regular task running at priority 0 can stop your task from ever getting any CPU simply by always being busy and never waiting.

zzd10h wrote:@Broadblues

Solution is simple remove broken sftware like limpidlcok from your system.

But these "broken" softwares worked well under 4.1.6. Why FE broke the compatibility with these not very old programs ?

Well assuming Deniils theory is correct, runing at alow priority while holding such a lock, leaves you at the mercy of small chnages in the way the scheduler, internal graphics library lock timig etc.

And limpid clock is of 2006 vintage so likely not using Compositing for it's transparency etc.

@broadblues
Thank you. As I wrote, i have the same problem but not with limpidclock but with photoframe docky.
I will increase amidock priority to see if it helps.

I gave up using LimpidClock months agos, I've just tried and I get no jerky mouse since you can modify the priority of LimpidClock using the menu (I choose -36). With LipidClok set to defautls, you'll get a jerky mouse (and display) every second. Just change its priority and the trouble is gone.

LimpidClock is not the culprit of the jerky mouse trouble when the X1000 experiences a huge load on its CPU. Even now I can experience this effect on seldom times (but far less than before since I'm now using a Radeon HD).

Something in FE for X1000 has changed and made this weird behaviour happen (that doesn't happen on Sam or AmigaOne XE).

broadblues wrote: And limpid clock is of 2006 vintage so likely not using Compositing for it's transparency etc.

The limpid clock display is an app icon so it uses whatever the WB uses for rendering its icons.

salass00 wrote:

broadblues wrote: And limpid clock is of 2006 vintage so likely not using Compositing for it's transparency etc.

The limpid clock display is an app icon so it uses whatever the WB uses for rendering its icons.

Oh interesting. Presumably it's using the WBAPPICONA_RenderHook like my AnimIcon program does. While your in that hook the workbench is locked, my tool just stamps a prerendered Icon using DrawIconState() but if Limpid Clock is doing someting more complex, that could trigger the "bug". Custom rendering is allowed so it needn't be using DrawIconState().