Flicker reduction attempts

Thanks to @ I’ve made great progress in reducing flicker while resizing. There are a few controls however that persist on being obstinate.

They are the PopupMenu, ComboBox, and RadioButton.

In 2017 r1.1 the ListBox header also becomes a problem.

In addition the PopupMenu does not draw correctly using darwinto. I’m still checking out the examples given here.

Here is the project if anyone is interested in searching for a solution. drawinto.xojo_binary_project

I’ve been working on this issue for about a month now myself. My issues are caused by using custom window styles so I can remove the title bar which forces me to resize the window myself in the mouse events.

Have you looked into FreezeWindow in the Xojo WFS? It might help depending on what you are doing.

You could also try BitBlt to resolve your DrawInto issues.

IMHO, these controls are fundamentally flawed in the framework and any amount of trickery isn’t going to fix this.

Even moving them 1 pixel causes them to flicker so a fps limiting system isn’t going to help this.

My only suggestion would be to place everything inside container controls, set their locking method as desired then just move the container control around. See if that produces any better results.

See the thread here https://forum.xojo.com/37786-controls-flickering-on-scroll

The updated project is here if you want to take a look at it:

https://www.dropbox.com/s/sij0dccfkynt303/ScollTestFlickerFix.xojo_binary_project?dl=1

Just tick and untick the box and see what happens.

You will notice that the radio’s are still having issues, I never had any feedback from Xojo about that, windows love is unfortunately severely lacking.

There might be issues where having individual controls on the window and refreshing them all in a row causes issues, if you have them in the container control will only cause a single “draw” in the framework (who knows).

Good luck

FWIW WS_EX_COMPOSITED is the best thing I’ve found to completely remove the flickerrrrrrr. Try it. Examples here: https://forum.xojo.com/1452-windows-flicker-in-the-ide/p3#p19214

Comes with it’s own set of other issues depending on what other styles you are trying to implement along with it.

I’ve been trying to write my own double buffering for a few days now like as described on this site: http://www.catch22.net/tuts/flicker-free-drawing

Still no luck. :confused:

@ if you are ever on twitter again I just followed you. :wink:

Thanks, getting an sms from twitter at 3:30am reminded me that I should turn that function off :wink:

You’ll be lucky to get any custom drawing done. Until this is fixed (if ever) I feel there’s no chance getting to the bottom of any of this.

If you’re going the route of creating your own double buffering routines, doesn’t it kind of defeat the point of using a framework that should be taking care of all that?

[quote=332777:@]Thanks, getting an sms from twitter at 3:30am reminded me that I should turn that function off :wink:

You’ll be lucky to get any custom drawing done. Until this is fixed (if ever) I feel there’s no chance getting to the bottom of any of this.

If you’re going the route of creating your own double buffering routines, doesn’t it kind of defeat the point of using a framework that should be taking care of all that?[/quote]

Apologies for that late notification. :confused:

I agree but I have to try and fix it somehow. I can’t stand the flickerrrrrrrrrrrrr.

Thanks so much for the link to your Z order info. I will study it and see how this info can help me.

I have found that SetWindowPos produces less flicker than resizing using something like Window1.Width = Window1.Width + x in MouseDrag in my custom windows. Most likely related to what you have discovered no doubt.

Flickering is much less noticeable with Windows 10 Creative update. But still there is some.
Unfortunately you cannot remove it completely because Windows itself does not use double buffering at all. macOS does and that’s also the main reason why flickering is a no-issue on macOS.

I just tried it and the flicker was the same.

Flicker is the result of screen refresh, which may be better or worse depending on the graphic card as well.

I have an app I designed for macOS that has 3 splitters (1 vertical, 2 horizontal), not to mention a few controls that appear/hide based on the current app state. On macOS this works great, and looks wonderful.
On Windows it is an awful mess…
Some of the declares and such I have found around here don’t seem to help (not to mention were 32bit only)
I have tried to add #IF target to delay some of the live screen refresh…
but that looks even worse as the splitters are now over the panes until you release the mouse, and then sometimes the screen doesn’t redraw “right”…

I guess there is no magic bullet?

I don’t know any way to have true splitters that do not flicker under Windows. And even I never tried anything as complex as what you describe.

That is where the cross platform abilities of Xojo encounter their limit. It may be time to refactor the UI to better suit the target platform.

I managed to reduce “most” by delaying the update of everything on the window except the one slider being moved until “mouseup” event… it isn’t perfect (but then it IS Windows :slight_smile: ), but is better than the strobe show I had before…

I also found that by moving the z-Order of the splitters to the front helped a lot, since it wasn’t trying to redraw things it didn’t need to

Indeed as found out, Xojo draws windows the wrong Z-Order way, which increases flickering.