[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.
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.