How to fix canvas flicker in Windows 7/8/10?

Admittedly, I realized that years ago constructing this custom interface was not the best way, but I have a canvas with other canvasses overlayed on it. On the MacOS, it works beautifully with no issues whatsoever. However, on Windows, it flickers terribly. It behaves just terribly. Is there a way to fix this? I know the MacOS double buffers to prevent this type of thing, can I do the same with Windows?

I am trying to avoid reconstructing this interface for this old project.

Thanks

Don’t overlay canvases. Draw everything in a single canvas.

One compromise to that… take you main background canvas and ditch it.
Draw what it would have drawn in the window’s paint event.
Then you only have some canvases on a window.
May not help, but worth a try.

Set erasebackground to false on the canvases.

A workaround that leaves as much code ‘where it is’ as possible:

[quote]move all your canvases off the window so they are ‘invisible’
In the window’s paint event, use .drawpicture or .drawinto to draw the contents of the canvases to the window graphics.
[/quote]

Wait for enough people to complain about it for Xojo to actually consider it important enough to be looked at?

And once your beard is totally white consider to change the IDE you’re using…

Enable DoubleBuffer and disable Erase Background for Windows.

[quote]Enable DoubleBuffer and disable Erase Background for Windows.[/quote] How?

They are switches in the IDE for the canvas.

That’s what I’ve used with WIN7 and haven’t experienced a flickering canvas, even with a canvas within a canvas within another. I’m not sure about a canvas overlapping another canvas, ie. over the edge of the other.

The “flickering” that I’ve experienced is with labels when tabbing between text input fields. Absolutely horrible. I have, however, come up with a “dirty” method that helps eliminate that issue.

[quote=338569:@Jeff Tullin]One compromise to that… take you main background canvas and ditch it.
Draw what it would have drawn in the window’s paint event.
Then you only have some canvases on a window.
[/quote]

Good idea to simplify, but won’t help. It’s the drawing that creates the flicker of anything on top.

The only way to be flicker free is to draw everything in the window or in a canvas. Eventually, set the said canvas as double buffer.

Problem is always the same. Someone starts a project in Mac, where flicker is almost unheard of, stacks controls left and right, then compiles on Windows and scream in horror.

Don’t stack controls in Windows. Period.

And (from experience) , dont have them too close together , or they can trigger each other’s paint events needlessly

The flickering in Windows is now going on for years. I really do not understand why Xojo inc is not solving this serious flaw which for some type of applications is a true showstopper.

It is something an end user notice, so it should be fixed years ago too.

Reading Eugene Dakin pdf ebook on Canvasses can also help you on the right track.

[quote=338611:@Chris Verberne]The flickering in Windows is now going on for years. I really do not understand why Xojo inc is not solving this serious flaw which for some type of applications is a true showstopper.

It is something an end user notice, so it should be fixed years ago too.[/quote]

For some reason, Xojo is drawing control in opposite order of what VS does. worked on that and it does reduce flicker quite a bit.

That said, don’t expect miracles. Win32 controls do not have double buffering like Mac does.

Any app created on Mac will need refactoring to work fine on Windows. This is the limit of Xojo’s cross platform abilities.

Even MS own use of Win32 controls that are not self drawn flickers
We’ve posted examples of them over the years

[quote=338623:@Norman Palardy]Even MS own use of Win32 controls that are not self drawn flickers
We’ve posted examples of them over the years[/quote]

We all know MS has it’s own problems. Even if so, there must be a way to get rid of it. Because not all applications have flicker (if any) some do (even without canvas) flicker like madness. I’ve not seen this happening on any windows forms applications or any other yet. Say a browser with tabs etc… or any application for that matter.

i’m sure there are some, just not that many.

.Net completely takes over drawing and double buffers so its more like OS X and so shouldn’t exhibit flicker.
So any of the MS UI frameworks based on .Net should benefit (WPF, Winforms, etc)

Anything using native Win32 controls can exhibit this.
see https://msdn.microsoft.com/en-us/library/windows/desktop/bb775501(v=vs.85).aspx#ownerdrawn_user

google for “native win32 controls flicker” and you’ll find plenty of other places mentioning exactly this issue about win32 controls

[quote=338626:@Norman Palardy].Net completely takes over drawing and double buffers so its more like OS X and so shouldn’t exhibit flicker.
So any of the MS UI frameworks based on .Net should benefit (WPF, Winforms, etc)

Anything using native Win32 controls can exhibit this.
see https://msdn.microsoft.com/en-us/library/windows/desktop/bb775501(v=vs.85).aspx#ownerdrawn_user

google for “native win32 controls flicker” and you’ll find plenty of other places mentioning exactly this issue about win32 controls[/quote]

Win32 flicker only happens when the Win32 coder doesn’t understand the correct order of things like when or when not to use the features at their disposal (clipping etc) or when or when not to draw to another surface before painting that completed render to the control.

Of course if you google “native win32 controls flicker” you’re going to find lots of posts about it because people rarely take the time to read up on something and they want the solution yesterday.

.Net does NOT completely take over drawing (in some mystical sense) and it certainly doesn’t double buffer by default. To enable double buffering on a form you have to explicitly set the DoubleBuffered property to true.

The double buffering that .Net provides in not some magical system that has been kept secret by Microsoft for them alone to achieve and for others to only dream about. Its provided by the same Win32 calls that you or I can make with Declares. The source code for the entire .Net framework is provided here, you can take a dive into it and check for yourself. It is merely a huge wrapper for Win32, much like Xojo. They are however starting on a grounding that the controls have been placed onto the forms in the correct order in the first place which gives them a significant advantage.

Considering the Xojo framework places controls onto the form in reverse order there will always be issues. Controls that a Xojo developer expects to be at the front are actually being placed behind other controls and being punched through to the front by the Xojo framework. Windows has no idea whats going on, it cant use features that have been developed over the years to eradicate flicker, its a total mess.

This has been clearly shown by the post here and what response did it receive? A response about me possibly using the IDE incorrectly! Did anyone actually read and process the post? From then on its a complete ghost town from Xojo. I think its quite telling, shocking in fact that there’s no follow up on this.

Every time flicker is raised the old adage that “oh dear, did you try ticking that thing on?, didnt you know Win32 controls do this, you just have to accept it” is just getting old.

When you get a new Windows interacting with what will probably be their first Xojo produced application, what example does this set? This is merely 20 controls in a scrolling pane, flickering and chopping, like its running on a PC from 1998. If Xojo cant even get this right in their IDE, what chance do us “mortals” have?

It feel like that there’s too much Windows development happening in VMs. They tend to smooth all this out and provide the user with a sanitised version of what is happening in real life. If this is the case, I suggest everyone working at Xojo get themselves a Windows machine and actually play with their IDE and sample projects and see what the rest of us are putting up with.

I would not expect them to completely rebuild how the Windows UI framework works in Xojo. Maybe it was a historical accident or intentionally done this way and not thought to be as bad as it is.

At earliest I suspect we could see it when the new framework gets desktop controls as that would be an obvious opportunity to introduce breaking changes. The downside is there has been no indication as to when the desktop will get the new framework at all.

[quote=338631:@]Win32 flicker only happens when the Win32 coder doesn’t understand the correct order of things like when or when not to use the features at their disposal (clipping etc) or when or when not to draw to another surface before painting that completed render to the control.
[/quote]
I’d expect MS to do it right - but they still have places where they use a plain Win32 control and they get flicker like mad as well.

You mean MY response ?
You need to reread my response if you think I said anything even approximating “you’re using the IDE wrong”

[quote=338631:@]Did anyone actually read and process the post? From then on its a complete ghost town from Xojo. I think its quite telling, shocking in fact that there’s no follow up on this.
[/quote]
Probably NOT as reading & replying on the forums is NOT part of our job descriptions
We do it when we have a few “spare” moment mostly
Which is why we repeatedly tell people don’t expect that a post on the forums is the same as a bug report
Its not
Not in any way