2018 R2 Canvas Flickering

My custom canvas listbox is now flickering in 2018 R2. X64 Win 10 in a project of mine. Not sure if it matters, but I tried with double buffering enabled also. It flickers for both 32 and 64 bit.

The gif shows both 2018 R1.1 and 2018R2.

Anyone else experiencing this? I haven’t submitted a feedback case yet.

Have the same problem with a listbox in my project.
I am using windows 10 pro.

We are having similar issues with labels on canvases in 2018R2 and the Treeview we use. See Feedback case 52217 - Window UI FPS reductions since 2016r3 that JulianS submitted. More than likely this is the same thing you are experiencing. It’s more apparent in Windows 7, than Windows 10. Our users will never be able to accept the flashing/flickering. If we ever plan on getting past 2017R3, we need this to get resolved for Windows.

We need users to add this feedback case #52217 to their “My Top Cases” in order to get it bumped up in priority.

Then why not let em get there with just 1 click? :wink:

feedback://showreport?report_id=52217

AFAIK William is working on some changes and I think a couple are done, but too late to include in R2.

Feedback Submitted Last Night:
feedback://showreport?report_id=52928

Verified.

[quote=400023:@Thomas Pittman]

We need users to add this feedback case #52217 to their “My Top Cases” in order to get it bumped up in priority.[/quote]

It’s current’y ranked 5th…Seems pretty high to me!

Can anyone explain this. I triplicated a my canvas control and put ONE listbox control on a window. When I don’t load any data into the listbox, all 3 canvas controls work fine. Once I put data into the listbox, the FIRST canvas control will only re-paint itself when the window is re-positioned.

If I put TWO listbox controls in the window, ALL THREE canvas controls become unresponsive and even the first listbox becomes semi-unresponsive:

Looks like the canvas is having a lot of CPU load . Maybe you used .refresh a lot? Try changing that to .Invalide(false). That will speed up a lot of things for sure.

something in the listbox control is eating up CPU.

I never use refresh in the canvases, only invalidate.

Possibly related to this post: flooding-the-log-cgdataprovidercreatedirect-invalid-size-0/0#p382973

Chad, do you have any code paths from inside the Canvas.Paint that can reach a Canvas.Invalidate? If you do then you could end up with an endless loop of paints that only shows its head when you add more controls which end up clogging the event loop.

I just checked, and thankfully, I only call invalidate in ONE place. The entire control is drawn to a picture and then invalidate is called where the paint method only draws the picture.

Setting transparent=false on the canvas property alleviated some of the issues, but exposed another “bug” regarding a super’s properties via Inspect Behavior. Hijacking my own thread here, but if you disable transparent property via “inspect behavior” and then close the dialog, Transparent is gone if you try inspect behavior again. I had to delete the class from the project and re-insert it to get Transparent back. Odd

Here’s some profiling data:

I could probably make some tweaks under the hood, but nothing stands out as absurd to me.

If your PAINT EVENT consists only of

g.drawpicture myPicture,0,0

Then I suggesting setting ERASEBACKGROUND and TRANSPARENT both to FALSE
and if you are putting your “picture” into BackDrop, then don’t

[quote=400222:@Dave S]If your PAINT EVENT consists only of

g.drawpicture myPicture,0,0

Then I suggesting setting ERASEBACKGROUND and TRANSPARENT both to FALSE
and if you are putting your “picture” into BackDrop, then don’t[/quote]

Transparent = False got rid of the flickering.(Still a bug acknowledged by Xojo).

EraseBackground is not a property. Did you mean something else?

Weird!
https://documentation.xojo.com/index.php/Canvas.EraseBackground

but it’s not in this list:
https://documentation.xojo.com/index.php/Canvas

and it’s not coming up at all in code completion or in inspect behavior. It’s showing up as DEPRECATED when I tried to compile Erasebackground = false.

Erasebackground has been removed unless it was turned on using an older version of Xojo then it might be in the advanced (cog) settings area of the inspector when selected on the canvas.

https://documentation.xojo.com/index.php/Canvas.DoubleBuffer notes:
If DoubleBuffer is True, then you should set EraseBackground to False. If EraseBackground is not disabled, then it will cause the Canvas to flicker.

But I don’t see an option to set EraseBackground to False from the IDE. Saving a sample project I get as default:

Begin Canvas Canvas1 AcceptFocus = False AcceptTabs = False AutoDeactivate = True Backdrop = 0 DoubleBuffer = False Enabled = True EraseBackground = True Height = 272
and changing DoubleBuffer from the IDE to True:

Begin Canvas Canvas1 AcceptFocus = False AcceptTabs = False AutoDeactivate = True Backdrop = 0 DoubleBuffer = True Enabled = True EraseBackground = True Height = 272

It will be good if we change the DoubleBuffer to True change the EraseBackground to False, at least for new people using Xojo.

Also, I don’t fully understand https://documentation.xojo.com/index.php/Canvas.EraseBackground

[quote]Indicates whether the entire Canvas is erased when doing any drawing operations or resizing.

Notes
It defaults to True for backwards compatibility.
This property is only used on Windows. Its setting has no effect on macOS or Linux.
If you set DoubleBuffer to True, then you should set EraseBackground to False. Otherwise, it will cause the Canvas to flicker.[/quote]
What backwards compatibility?
Canvas.EraseBackground was first introduced with 2005r1, maybe is time to set it as False as default?

Edit: this with new project and 2018r1.1, I’ll test with r2

Chad, are you able/willing to PM/post the code? I can take a look and see if you want.

[quote=400044:@Chad Posner]Feedback Submitted Last Night:
feedback://showreport?report_id=52928

Verified.[/quote]
Status: Fixed