Israel
MediaPortal Version: Media Portal 1 RC2 (I think) "MediaPortal v0.9.2.0 is starting"
MediaPortal Skin: Blue Two
Windows Version: XP SP3
CPU Type: Intel E2180 Core 2
HDD: WD 250GB Sata
Memory: 1G 800
Motherboard: Gigabyte
Video Card: Intel GMA O.B.
On slow computers when viewing shares in an icon layout the scroll up or down is jerky and slow.
Reproduced on fast computer with CpuKiller3.
Started debugging and this is what I found:
Application_Idle on a fast computer is called at constant intervals, at about 0.04 seconds.
On a slow computer Application_Idle() is called once every 0.04 seconds and 0.15 seconds intermittently.
Measured this by printing the startFrame member variable.
Because of long delay of 0.15 seconds the scroll is slow.
To make things worse WaitForFrameClock() adds a delay on every scroll step.
WaitForFrameClock calculates the time to wait from startFrame, but the delays are on another level outside the scroll cycle.
I suggest that WaitForFrameClock() calculate the correct delta needed by checking the _scrollCounter multiplied by DesiredFrameTime
Now if there is a drift, mediaportal should skip scroll steps and increase the scroll size.
Working on a solution and trying to find the cause for the delays.
MediaPortal Skin: Blue Two
Windows Version: XP SP3
CPU Type: Intel E2180 Core 2
HDD: WD 250GB Sata
Memory: 1G 800
Motherboard: Gigabyte
Video Card: Intel GMA O.B.
On slow computers when viewing shares in an icon layout the scroll up or down is jerky and slow.
Reproduced on fast computer with CpuKiller3.
Started debugging and this is what I found:
Application_Idle on a fast computer is called at constant intervals, at about 0.04 seconds.
On a slow computer Application_Idle() is called once every 0.04 seconds and 0.15 seconds intermittently.
Measured this by printing the startFrame member variable.
Because of long delay of 0.15 seconds the scroll is slow.
To make things worse WaitForFrameClock() adds a delay on every scroll step.
WaitForFrameClock calculates the time to wait from startFrame, but the delays are on another level outside the scroll cycle.
I suggest that WaitForFrameClock() calculate the correct delta needed by checking the _scrollCounter multiplied by DesiredFrameTime
Now if there is a drift, mediaportal should skip scroll steps and increase the scroll size.
Working on a solution and trying to find the cause for the delays.