Controls flickering on scroll

[anon20074439]

I have created the following example to show an issue I have when scrolling a ContainerControl (and/or Canvas) containing controls.

As you can see there is horrible flicker!

I am performing the move in ValueChanged on the scrollbar “ContainerControl11.Left = 0-me.value” I assume that is the “correct” way to move the container around?

I have managed to reduce the flicker to the following using some code here

There is a little flicking here, its hard to pick up with the gif. The ComboBox, RadioButton and Labels are flickering, but everything else is pretty solid.

Does anyone have any more pointers as this just looks nasty.

Thanks in advance.

[Norman_P]

Ah the sheer joy of OS drawn Win 32 controls
Which is why MS mostly doesn’t use OS drawn control and relies on self drawn controls instead (and there are places in VS 2015 you can still find they do use OS drawn controls and you get the exact same issues)

We don’t use self drawn controls

Not sure if freeing updates and unfreezing them would help or hurt
Something like freeze the update, do the scroll unfreeze the update might alleviate the flickering
Or I could be really wrong on that and it might make it worse

Public Sub FreezeUpdate(extends w as Window)
  #if TargetWin32
    // Use the WM_SETREDRAW message instead to lock the redraw
    // state of the window (note that this can be used for controls as well)
    Const WM_SETREDRAW = &hB
    call SendMessage( w.Handle, WM_SETREDRAW, 0, 0 )
  #endif
End Sub

Public Sub UnfreezeUpdate(extends w as Window)
  #if TargetWin32
     // Use the WM_SETREDRAW message instead to unlock the redraw
    // state of the window (note that this can be used for controls as well)
    Const WM_SETREDRAW = &hB
    call SendMessage( w.Handle, WM_SETREDRAW, 1, 0 )
  #endif
End Sub

[anon20074439]

Thanks Norman.

I think that’s the exact code I linked above. I used it and it took the flickering from image 1 to image 2. I’m still getting some flicker just on ComboBox, RadioButton and Labels, are they rendered differently somehow?

[ChristopheDV]

[quote=308457:@Norman Palardy]Ah the sheer joy of OS drawn Win 32 controls
Which is why MS mostly doesn’t use OS drawn control and relies on self drawn controls instead (and there are places in VS 2015 you can still find they do use OS drawn controls and you get the exact same issues)

We don’t use self drawn controls

Not sure if freeing updates and unfreezing them would help or hurt
Something like freeze the update, do the scroll unfreeze the update might alleviate the flickering
Or I could be really wrong on that and it might make it worse

Public Sub FreezeUpdate(extends w as Window)
  #if TargetWin32
    // Use the WM_SETREDRAW message instead to lock the redraw
    // state of the window (note that this can be used for controls as well)
    Const WM_SETREDRAW = &hB
    call SendMessage( w.Handle, WM_SETREDRAW, 0, 0 )
  #endif
End Sub

Public Sub UnfreezeUpdate(extends w as Window) #if TargetWin32 // Use the WM_SETREDRAW message instead to unlock the redraw // state of the window (note that this can be used for controls as well) Const WM_SETREDRAW = &hB call SendMessage( w.Handle, WM_SETREDRAW, 1, 0 ) #endif End Sub [/quote]

Does this also work for 64bit builds? (you are using TargetWin32)

[Michel_Bujardet]

@308490:@Christoph De Vocht

Does this also work for 64bit builds? (you are using TargetWin32)

Win32 is the name of the framework, like Cocoa in macOS. Not the executable bit number.

[Norman_P]

@308490:@Christoph De Vocht

Does this also work for 64bit builds? (you are using TargetWin32)

It may well need to be a different declare for 64 bit Windows
I didn’t check MSDN and just pulled this out of some existing code
So it may need to be written as

Public Sub FreezeUpdate(extends w as Window)
  #if TargetWindows
   #if Target32Bit
    // Use the WM_SETREDRAW message instead to lock the redraw
    // state of the window (note that this can be used for controls as well)
    Const WM_SETREDRAW = &hB
    call SendMessage( w.Handle, WM_SETREDRAW, 0, 0 )
  #else
    // 64 bit windows declare here
  #endif
#endif
End Sub
Public Sub UnfreezeUpdate(extends w as Window)
  #if TargetWindows
   #if Target32Bit
    // Use the WM_SETREDRAW message instead to unlock the redraw
    // state of the window (note that this can be used for controls as well)
    Const WM_SETREDRAW = &hB
    call SendMessage( w.Handle, WM_SETREDRAW, 1, 0 )
  #else
    // 64 bit windows declare here
  #endif
  #endif
End Sub

@308506:@Michel Bujardet

Win32 is the name of the framework, like Cocoa in macOS. Not the executable bit number.

Not in this case
It is the old synonym for TargetWindows
I could literally write

#if TargetWin32
#if Target64Bit
... whatever 64 bit declares
#endif
#endif

but since we now have both TargetWindows in the same manner we have TargetLinux and TargetMacOS it just reads nicer

[Tim_Hare]

I have to ask, Is it really necessary to scroll the controls? I consider that to be bad UX. Is it possible to group the controls logically onto pages of a tabpanel or something? I personally avoid having to scroll at all costs.

[anon20074439]

Honestly I wouldnt do this, but it was just a test project to highlight the issue. However just having a control moved on a window resize (which is quite common) would cause the problem, this many controls is just showing it on a higher spec pc.

[Tim_Hare]

It’s less jarring when done on window resize, because pc users have come to expect things to be less than perfect when resizing a window.

[Norman_P]

[quote=308457:@Norman Palardy]Ah the sheer joy of OS drawn Win 32 controls
Which is why MS mostly doesn’t use OS drawn control and relies on self drawn controls instead
[/quote]
I know of no way to reduce flicker to 0 using Windows and OS drawn Win32 controls
Win32 does not double buffer like OS X

VB mostly avoided OS drawn controls and used “self drawn controls”
As do Word, Excel, Powerpoint etc
As I mentioned the one spot we know of where MS does use them in VS they flicker like mad there too

Long term it would likely need to be a move to WPF, WinForms or Universal or whatever UI kit MS is now saying is the future that will make the Windows UI toolkit fully double buffered so flicker is non-existent

[anon20074439]

Thanks for the info Norman. I’ll try to design around it.

[Norman_P]

I’d suggest posting your sample code
It cant hurt to let others kick at it
There may be something else to try once we see code
You never know

[anon20074439]

[quote=308724:@Norman Palardy]I’d suggest posting your sample code
It cant hurt to let others kick at it
There may be something else to try once we see code
You never know[/quote]

Here’s a link to the test project. Its super simple code.

https://www.dropbox.com/s/3tvenrnt702bx38/ScollTest.xojo_binary_project?dl=0

You might also see that the “Untitled” label also changes when the scrollbar is moved (see below) from nice to as if its been scaled horizontally a pixel or two.

[Norman_P]

FYI _ I only did this quickly on one of my VM’s so it may behave differently on real pc

Try this

1. change scrollbar1.valuechanged to just the following

		ContainerControl11.Left = 0-me.value
		ContainerControl11.Invalidate

2. add a method to ContainerControl1 as follows

Public Sub Invalidate(eraseBackground As Boolean = True)
  for i as integer = 0 to me.ControlCount() - 1
    if me.Control(i) isa RectControl then
      RectControl(me.Control(i)).Invalidate
    end if
  next
End Sub

3. there does seem to be some weirdness with labels with transparent set to ON so IF This is not a requirement then turn it off on Label1, Label2, Label3

[anon20074439]

1+2) Not much different Norman. It went back to image 1 above.
3) This worked

[LangueR]

For the specific example, do you really need the LiveScroll?

[Michel_Bujardet]

Langue is right, it is no point to use LiveScroll in this case. I would probably set a scrollbar steps so it moves for instance 3 pixels at a time.

There is another thing you can do, especially since I see you are moving the slider pretty fast. Whenever one tries to draw faster than 60 frames a second, bad flicker occurs.

Limit the scroll actions to one per 60th a second. Use ticks with something like this in slider ValueChanged :

static previousTicks as double = Ticks TimerSlide.Mode = Timer.ModeOff TimerSlide.Mode = Timer.ModeSingle if ticks >= previousTicks+1 then ContainerControl11.Left = 0-me.value ContainerControl11.Invalidate previousTicks = Ticks end if

TimerSlide is here to complete the scroll in case the last change was not taken into account because it was before tick.

It contains this into Action :

ContainerControl11.Left = 0-me.value ContainerControl11.Invalidate

[Norman_P]

[quote=308737:@]1+2) Not much different Norman. It went back to image 1 above.
3) This worked[/quote]

you have to do 1 + 2 + 3

[anon20074439]

@308808:@Norman Palardy

you have to do 1 + 2 + 3

I did them all at once I’d be impressed if changing transparency on Label1,2,3 altered all the flickering on the form I was letting you know what happened at each stage. Overall it went back to image 1 in terms of flickering but the number 3 fixed the label issue.

@308708:@Tim Hare

I have to ask, Is it really necessary to scroll the controls? I consider that to be bad UX. Is it possible to group the controls logically onto pages of a tabpanel or something? I personally avoid having to scroll at all costs.

Its surprising how many windows apps (non-uwp) actually use scrolling windows with controls. I guess I have just become immune to spotting them. Here’s an example from a program I regularly use called BeyondCompare, they are using both tabbed controls and scrolling as there’s a lot of options in this program.

I also checked with Inspect and it does use standard windows controls, not custom ones.

[anon20074439]

[quote=308751:@Michel Bujardet]static previousTicks as double = Ticks
TimerSlide.Mode = Timer.ModeOff
TimerSlide.Mode = Timer.ModeSingle
if ticks >= previousTicks+1 then
ContainerControl11.Left = 0-me.value
ContainerControl11.Invalidate
previousTicks = Ticks
end if[/quote]

This is almost a full fix however I’m still seeing some trailing edge corruption, but not on every control, see here:

While this looks like a good fix it should technically be linked to the refresh rate of the monitor not just 60Hz

Unfortunately the Screen class doesn’t return the Hz of the monitor. So I’ll probably need to dig this out of the registry if this does become my fix for the problem.