I go for 60 Hz because that is the physiological limit of perception with usual users (I have been told some see the difference between 60 and 100).
Don’t forget that scrolling is usually fast enough for people to not even notice if controls are fully formed during the scroll.
As said above, combining several techniques is key.
The problem is with the onset of >60Hz monitors though. I know from personal experience that it is glaringly obvious when you see the different between a 120Hz or 144Hz monitor and a 60Hz.
With the use of the program on a higher refresh monitor I assume (not tested) It would introduce the same flicker, which is why I’d prefer to read it out of settings rather than having a hard limit.
But yes, I shall continue to play with things and see what I come up with, thanks again.
A scroll on a business app is not the same as a video game. We are talking about reducing flicker. Not drawing planes at 144 frames a second.
Who said I was making a business app? I’m making a desktop app aimed at gamers/videograhpers. If they have a 144Hz monitor, I dont really want it to look like a mickey mouse app, sorry for having standards.
Ouch. So now you have to find a way to detect the refresh rate of the monitor. Good luck, Sir.
Do you get the same problems scrolling vertically instead of horizontally?
Yes
That was the easy part 
but I’d be interested in why this isn’t in the Display class as it must be called to get the dimensions of the display in the first place. Just a proof of concept, its rough code borrowed and tweaked from the old RB forum I believe, it need tweaking to detect when the app moves to a different monitor etc. however I might not need it if I can drop the FPS limiter altogether.
[code]Public Function DisplayFrequency() as Integer
dim frequency as Integer = 0
#IF TargetWin32
Const ENUM_CURRENT_SETTINGS = -1
Const ENUM_REGISTRY_SETTINGS = -2
Declare Function EnumDisplaySettingsW Lib “user32” Alias “EnumDisplaySettingsW” ( Null as Integer, ModeNumber As Integer, DevMode As Ptr ) As Integer
dim devMode as MemoryBlock = new MemoryBlock( 188 )
if EnumDisplaySettingsW( 0, ENUM_CURRENT_SETTINGS, devMode ) = 0 then
Return 0
end if
frequency = devMode.Long( 184 )
#ENDIF
Return frequency
End Function
[/code]
I was looking through ListBox.Refresh again just in case I missed something and I did, I noticed that it could take a parameter for erasing the background so I gave it a try, heck why not I’ve tried just about everything else.
Smooth as silk!!! with just two lines of code. The only issue I am noting is that the radio doesn’t draw correctly until you slow/stop the move. I’ll come back to that further on.
ContainerControl11.Left = 0-me.value
ContainerControl11.Refresh(false)
Now this has me wondering. Shouldn’t there be a massive trail of the controls if I have passed false to Refresh? I’m asking for a redraw of the whole container control and not asking it to render the background, yet it is performing a full wipe/clear of the container before refreshing the controls.
If Refresh(true) does blank the background why is it doing so when I send false? Are there two background wipes going on with Refresh(true) and by setting Refresh(false) I’m actually disabling one of them and eliminating a flicker problem?
Just a thought. What do you think?
Now about the radio problem (again with just the two lines of code), see here:
As you can see the radio isnt drawing until it has time. Being the only control that does this I’m wondering if there’s an issue with it in the framework. Of course it works if I put in Michel’s FPS limit code from above but I’d like to try and get this as clean as possible.
What do you think?
I still think you should make sure the app does not try to draw faster than the refresh rate. Drawing faster in the end is futile, since the screen cannot render it anyway.