Why do you use separate canvases?
Read the SuperDraw article in xDev 12.5 about how to do drawing in an object oriented way, eg many objects on a single canvas that you can move, resize, change etc
That article really should be mandatory reading for anyone using the canvas control.
Probably because the SpriteSurface was deprecated?
This may seem a silly question to some, but where can I find the SuperDraw article in xDev 12.5 about OO drawing technique? I am having the same issue as others with the flickering from Windows, almost to a showstopper point, but so far I am try to work around it so maybe this can help. I’ve considered other drawing techniques and using a single canvas but it does seems to make XOJO less viable as a RAD tool if it takes advanced coding to get around this.
Just my two cents …
Page 48. and you should be able to buy just the one issue: http://www.xdevmag.com
It’s not really “advanced coding”. The problem is that using separate canvases to make up one picture is simply the wrong approach. You get problems with the different objects overlapping or being too close, creating cascades of redraws.
Instead you have just one canvas and an array of objects (like rectangle, star, image, text, etc) you want to draw.
So you create a buffer picture and draw all the objects to it (the objects know how to draw themselves, be selected, moved, deleted, etc). That happens in the background without any flicker. Similar to what the Mac is doing anyway.
So all you do in the canvas paint event is draw the buffer picture.
Basically you introduce your own double buffering to Windows.
Reading the article will also open your eyes to object- orientation in ways no other article managed for me before.
Btw when you look at a painting by Rembrand, Van Gogh, Degah, etc do you think it weird that it is all painted on just one canvas, and not on many different smaller canvases stitched together?
If you watch a movie on your 50" screen does it seem unnatural that everything is happening on just one screen, instead of many smaller ones interacting with each other?
Of course not.
But when you use separate canvases, that’s exactly what you are trying to achieve. It’s more cumbersome, more effort, more complex to get it right. And quite frankly, most of the time you don’t.
And as Windows doesn’t have its own double-buffering, you have to supply it. But that’s easy when you use the right - and simple - approach.
Will you get completely flicker-free? Maybe not. But it should be nowhere near as bad as using a multitude of interacting canvases.
Btw, the article uses a canvas and a toolbar on a ContainerControl for easy reuse.
Personally I find it better and more flexible to just make a custom canvas class with an array of objects and code to draw those objects, and leave the toolbar and object definitions separate.
Btw I HAD gotten Marc’s permission to upload the code to GitHub. Will do it tomorrow when I’m at my Mac.
Hello,
I don’t know if this will help anyone. I’ve took the example project (12508project - SimpleDraw Complete) from XDev 12.5 magazine http://www.xdevmag.com/browse/12.5/ and made some modifications to remove any flicker (this work on my Win 10 machine without any issues).
The changes that I’ve done can be seen in the source code (I’ve commented all refresh commands).
On the canvas object I’ve deactivated: DoubleBuffer (for some reason I’ve notice that on Windows 10 the DoubleBuffer increases the CPU usage a lot) , EraseBackround and Transparent(there is no need for this as we draw on the entire canvas)
I’ve also added:
#pragma BackgroundTasks False
#pragma StackOverflowChecking False
#pragma NilObjectChecking False
#pragma BoundsChecking FalseThe above code can be useful(can speed up things) in the draw event.
Mainly the problem is on how the refresh is used in the code. In this example there is only one canvas object, I didn’t tested with multiple canvas objects.
https://www.dropbox.com/sh/5ceudlnbpwc1mup/AABQxWmfM8xiJzUArkzNsHGpa?dl=0
This and double buffering is the best solution to flicker. Most people coming from Mac tend to stack canvases, which is the absolute recipe for Windows catastrophe.
As SimpleDraw uses its own double buffering the build-in option is unnecessary
[quote]
#pragma BackgroundTasks False
#pragma StackOverflowChecking False
#pragma NilObjectChecking False
#pragma BoundsChecking FalseThe above code can be useful(can speed up things) in the draw event.[/quote]
It should be in a if not DebugBuild as you want the checking during testing
Just for transparency, it seems like I’m unable to post public information to <https://xojo.com/issue/47001> any more (can only send direct to Xojo), don’t be disheartened by William’s last comment on there, I have pointed Xojo towards the fix both in private and in the ticket. Here is a copy of what I have posted in the ticket that you can’t see:
[quote]William, I have just realised that I have not directly submitted this information to you or this ticket so I have no idea if it has go to you internally and others seeing the ticket might be disheartened that the solution I provided wont work for them if they use transparency.
FWIW:
[quote]As I can’t see how the framework handles the transparent drawing for the labels, it’s a bit hard for me to do much from this end as I can’t peer into the guts of the framework and see what is or isn’t being done/set.
I’m afraid that it’s not going to be an easy fix, the solution I provided was used to highlight the problem and prove that the z-order was wrong. I would be very surprised if it fixed the problem for all eventualities in one shot.
Here is the code that .Net uses to paint the background for all controls that have a custom background or transparency:
PaintTransparentBackground is the part that handles the transparent painting.
And if anyone doesn’t read the Windows channel, here’s feedback fixing flicker happening in a real project, not just a test project, this is what you should expect from the fixed Xojo framework in windows:
I gave up on windows flickering issues years ago and just accepted it. I appreciate Julian for not accepting the status quo and for trying to figure this out on his own. This is such a terrible problem, makes Xojo look bad and does not seem to be an issue in other development environments. If Julian’s research leads to a solution, I suggest Xojo give him a free license for a year or something. Fixing this is really a big deal. Long term, I think “non flickering” windows apps produced from Xojo will sell more Xojo licenses.
And more renewals.
+1 to that.
Many Xojo windows updates for the last couple of years have actively discouraged me from upgrading my Windows compiler.
(Direct2D problems, Huge increase in size of the compiled app due to the 20Mb of Text DLLs , painful installs due to the new Microsoft DLLs… it just feels like ‘all pain no gain’. )
Give me a good reason to upgrade, like proper 64 bit and no flicker, and I’ll accept the stuff above as part of the price to be paid.
+1 to the last 3 posts.
This is EXACTLY the position I find myself in. I’m using 2016R3 and haven’t installed the quarterly upgrades except for R4 which seemed to have even more issues. At this point I can’t see myself renewing my license.
Fortunately I’m a hobbyist developer. If I was doing this professionally, I don’t see how I could release software with these flickering issues - it makes the software look unreliable and dodgy. Yes, there are some workarounds but that requires extra work.
It’s a shame because I really love working with Xojo.
If you develop on windows for windows then your projects tend to scale up to the other targets, and yes that’s an admission that Windows could improve. However my windows applications work on Macos - every time. It seems to me you Macos people are using the wrong platform for development 
Come on Wayne. Have you seen how fast compiles are on Mac ? That alone makes me appreciate the Mac platform.
That said, I am confident on the longer run Direct2D could be beneficial for that platform, past the pimples.
[quote=340254:@Steve Kelepouris]+1 to the last 3 posts.
This is EXACTLY the position I find myself in. I’m using 2016R3 and haven’t installed the quarterly upgrades except for R4 which seemed to have even more issues. At this point I can’t see myself renewing my license.
Fortunately I’m a hobbyist developer. If I was doing this professionally, I don’t see how I could release software with these flickering issues - it makes the software look unreliable and dodgy. Yes, there are some workarounds but that requires extra work.
It’s a shame because I really love working with Xojo.[/quote]
Yep, I feel you. I want to have a graphics in a canvas that are transparent, that change when you mouse over them smoothly to something else. I can’t really get that now without turning off Erase Background and Double-Buffering on, which eliminates the graphic’s transparency and makes it look a little ugly. Or is there a way to do this in Windows 10, Xojo 2016R4.1?
This is one reason I haven’t renewed my license.
I recently refactored WaterMarker+ which was originally created on Mac with several Canvas. Once compiled on Windows it was unusable.
I used a single transparent canvas, no double buffer, and did not turn off erasebackground. Solid as a rock.
Of course, it is a tad more complex to do, but the rewards are evident.
One of the examples that can help do that kind of programming is CanvasDrawDrag in Graphics and Multimedia.