The real problem about SLOW drawings on Windows

It is not a secret that for years, the apps creted with Xojo, and Xojo IDE itself hs being SLOW and flicker on windows. In the las versions, the flicker problem it has gone, but the SLOW drawings of controls are much and much more noticeable each version.

Someone said that the Label contros where the culprit and have a better result using canvases with a DrawString on the Paint event. I tried this, and have a just slightly improvement on Xojo 2017, BUT in 2018 its the same SLOW drawing. That was odd, ad make me curious about why is the drawing SO painfully slow.

I knew that Xojo labels are NOT the native STATIC windows class, they are custom controls, so I made some tests creating some NATIVE controls on the window and comparing the speed of the Native controls VS the custom ones.

Drawing of the native controls are REALLY FAST and the UI feels great. Xojo custom controls are SLOW and it is frustraiting to work with a UI made of them.

Conclusion: the problem is not windows, nor the drawing, it is some bottleneck in the way xojo is managing the containers on which the custom controls are drawn, the worst part is that this problem is WORSE than ever on 2018.

Distributing an app whith a slow UI will make the developper and the app look BAD. I really hope this can help XOJO to solve this problem.

Please see the video for the comparissons.

Download video

So, we have 2 solutions, please vote.

  1. Use native STATIC control for labels FeedBack Case 52798
  2. Fix the behavior of custom controls FeedBack Case 52787

HOW did you manage to use the static controls?

Windows Api Calls

I just did a test, I don’t know if this will help or not, but for me it is strange.

Window 1 just 2 buttons, one to show Window 2 with 300 labels, the second to show Window 3 with 300 TextFields. Because TextField has more options I changed the following:

  • Border off
  • UseFocusRing off
  • BackColor to same color as the window
  • ReadOnly on
  • Text Untitled (to match the labels)

When I click on labels button, I can see Window 2 open and draw all the labels from right to left.
When I click on TextFields button, I can see Window 3 open and all TextFields there, no slow drawing effect.

Why TextFields appear on screen so much faster than Labels?

You‘re such a Microsoftie … :wink:

[quote=397706:@Alberto De Poo]I just did a test, I don’t know if this will help or not, but for me it is strange.

Window 1 just 2 buttons, one to show Window 2 with 300 labels, the second to show Window 3 with 300 TextFields. Because TextField has more options I changed the following:

  • Border off
  • UseFocusRing off
  • BackColor to same color as the window
  • ReadOnly on
  • Text Untitled (to match the labels)

When I click on labels button, I can see Window 2 open and draw all the labels from right to left.
When I click on TextFields button, I can see Window 3 open and all TextFields there, no slow drawing effect.

Why TextFields appear on screen so much faster than Labels?[/quote]

Because they are native controls?
Perhaps his static declares are slower?

Exactly the 2 reasons for this post, Text fields are Native, drawn directly onto the window. But Labels DON’T use the native control and they are drawn in a container. in 2017 this containers where slow (and drawn from left to right) For some reason, since 2018 r1 they are drawn from right to left but are EXTRA slow.

[quote=397706:@Alberto De Poo]I just did a test, I don’t know if this will help or not, but for me it is strange.

Window 1 just 2 buttons, one to show Window 2 with 300 labels, the second to show Window 3 with 300 TextFields. Because TextField has more options I changed the following:

  • Border off
  • UseFocusRing off
  • BackColor to same color as the window
  • ReadOnly on
  • Text Untitled (to match the labels)
    [/quote]
    Excellent diagnosis. I tried this as well, but I find that the baseline for the font is not correct for all except the default System 0 font. And using it as a replacement on all three platforms is impossible because of this since the variation in baseline differs - especially on Linux.

If you haven’t, you should post your example project into one of the feedback reports so the Xojo Devs have an active example.

Could you post your sample project?

Isnt this the flicker ‘fix’ (= workaround) whereby they reversed the drawing order of stuff ?

The real root cause hasn’t been addressed all these years. Don’t set your expectations too high.

And the real root cause is ??

Personally i think that that is the lack of a solid z-order system, but i am curious what you think it is.

[quote=397762:@Andre Kuiper]And the real root cause is ??

Personally i think that that is the lack of a solid z-order system, but i am curious what you think it is.[/quote]
I can’t say I know the technical details because I am just a hardware guy that uses software to jazz things up. But it is pretty obvious that whatever choices were made to provide controls and drawings on the windows system back at the start of RB were not consistent with the standard windows api or have not kept up with them. It is probably a mix of not using native controls, using the wrong drawing calls or order, etc. What I do know is that if I compile a fancier application (one that draws a lot of controls or shuffles pictures) in Xojo vs say VS or Delphi the perception of how fast the application runs is perceptible. And it seems that this last attempt at improving the “flicker” is just more lipstick, they slowed down the refreshes so it doesn’t change as fast (or at least that is the way it “feels” when the redraws happen). All I am saying is that this has been baked in the windows builds since I came into Xojo, and it has been getting progressively worse, unlike the Mac side of things were there may be a regression here or there, but it is quickly corrected. Having said that, Xojo is still the best RAD I’ve used. I just don’t use it for things I know will disappoint me.

I am mostly a mac user, and do not understand the intricacies of windows programming. All I know is that my mac users are very happy with my programs and my windows users (which outnumber the mac users) complain about the interface, but persist since my programs are scientific and they need the results. But when I test my windows programs I am sad to see such poor performance. But to make matters worse, the math performance of XojoScript has dropped significantly as I reported earlier. I am forced to do all my final compilations using 2017R3 or earlier.

It certainly feels as if Windows is an afterthought at Xojo. I can’t believe that this is true however. Now, we do know that someone at Xojo is actively looking into the issue. There is however a severe draught of Xojo comments on the threads related to the interface drawing speed.

There were some very good finds made by forum members. We have no idea however whether these things were already known, whether they make any difference or just serve the purpose of wasting our collective time.

I can understand that Xojo engineers stay away from the forum more than before. There is much to do and living on the forum takes away from development time. Forum dwellers are not always pleasant either. But some acknowledgement that this very serious issue is on the way to be resolved would be more than welcome at this point.

I’ve now added <https://xojo.com/issue/52217> to my Top Cases, because it was ranked 97th.

+1

30th now…

Now 14th.

We appreciate all the feedback, whether harsh or not, it is reality. We’re not happy about the way things are on Windows either so we’re actively pursuing our options (read whatever you want from that).

In the past we had better performance and could reduce the flicker with workarounds. Not an ideal situation, but …
Now we have (nearly) no flicker but but performance issues which we cannot simply workaround.

I hope that if Xojo Inc. can’t find a solution soon, we go back to the previous drawing system. Then Xojo Inc. can investigate further, and we can focus on other stuff again. :slight_smile: