The real problem about SLOW drawings on Windows

I read that this issue will be resolved. Thank you @William Yu !

For testing purposes, can you share how to do that? I’ve made something but seems I miss something.
Thanks

That is more or less what I did just sticking with 2015r4.1 and will continue to do so. I’m ready and willing to get back to renewing my Pro license when this issue is resolved. As much as I don’t like the flicker, I hate the slow performance of the new versions worse. And for what it is worth, my apps that are created with 2015r4.1 flicker a lot less on Windows 10, than they do on Windows 7.

Thats the SAD part. I renew my PRO licence at the end of 2017 for the promess of the solution to windows problems with 2018r1, BUT, as slow as it is, It cant be ussed to deply professional apps. So, it feels like a waste of money :frowning:

The good News, my FeedBack Case 52798 - Use the native STATIC control on windows for LABELS, is marked as IMPLEMENTED.

As labels are one of the most used controls in a window, this by itself will solve a good part of the SLOW drawing of the window.

:smiley:

Good news indeed. My Windows apps are small in control use in comparison to other member’s complex projects. Looking forward to the update and thankyou Xojo for listening to your forum members and taking action.

MIGHT solve …

Labels are one major bottleneck on Windows right now. Labels are not the only bottleneck. Hopefully, the Windows optimization initiative will address all or at least most of the current bottlenecks. Direct2D comes to mind.

Now, this news is definitely a great step in the right direction. There is hope.

Doesn’t seem to be in R2, and Petro ignores any requests for showing how to do it yourself …

Yeah anyway… @Pedro Ivan Tellez Corella How about posting your sample project. I would like to see it also.

Thanks Pedro for your info.
My app displays slower with 2018r1.1 than it was with 2014r3. I’ve spent countless hours trying to speed up the display.
A huge label array on the main window.
I changed the label superClass to textfield.
It looks ugly but WOW much faster!!

2018r2 is still awefully slow and unusable.
One of the culprits is the Label control not being native. Replacing it with the Textfield can indeed speed up things.

Still, it’s not the only problem why 2018r2 for Windows is so slow. Don’t think we can expect huge improvements in future versions unless Xojo Inc rethinks the current Windows framework.

Shucks! There was a glimmer of hope this morning when I saw the upgrade notification.
I need the text to be a different color and be dragable.
I can make textfields look like labels but can’t replicate all the label events.

Thats the key… normal Windows ‘labels’ are just static text , arent they?.. they draw words on demand and that’s it.
Essentially its parent.graphics.drawstring “thetext”
If all they are is a call to drawstring, there is nothing ‘there’ to receive events.

maybe subclass a canvas by adding a text property -
have the canvas itself be invisible at runtime,
have the parent draw the strings where the canvases would have been?

Eugene Dakin’s book ‘Implement Declares with Xojo on Windows’, page 249, shows how to create a static label using declares.
www.scispec.ca/index.php/books

Those who have been following this issue closely are aware that work is under way at Xojo to make significant improvements to the speed of Windows applications. Labels is certainly one area where we can expect vast improvements in an upcoming release. Such changes are however probably not so easy to integrate in a framework. It was too late to implement static labels in this release (a Feedback note suggests that it is coming). I am hopeful that a not too distant future release will finally implement the work that is on-going. I am ready to wait a bit more if the result is up to our expectations. (well… that may be asking for a lot… ;))

Those who have been following this issue are mostly those having problems and someone like me is waiting since Xojo 2016r4 they find solutions.
C’mon, I can’t change all the code every 3 months because they first decide to implement transparency then pseudo-transparency, then it come out it’s slow like hell and some controls are faked (Labels) and then the Canvas is not transparent anymore (sic!).

This is just crazy. :frowning:

I understand your point @Massimo Valle . I did not say or infer that change is without side effects, nor that everything is right the first time. That is precisely why I would wait a bit longer before something is pushed to prod: to have it as close to right as possible. Such back and forth and step to the side is not what we need or want. No argument there.

In fact, I expect that significant performance improvements will come with a bunch of impacts for us. Doing things differently in the framework will most likely impact the way we need to design our applications for Windows. Hopefully, such impacts will be manageable and hopefully it is going to be for the better on the long run. Call me an optimist.

Without sounding condescending, we’ve heard this before. It’s always coming, but never gets here. Every time I read the release notes for new version, I’m encouraged by the fixes and changes that are being made, but I’m 3 versions behind and I can’t take advantage of any of those fixes or changes. Really disappointing.