Possible solution for sluggish UI

Hi

I am still using Web 1.0

when I designed a screen with lots of control, I normally encountered delayed UI refresh upon running it . This is annoying specially when user is too quick clicking different button.

What is your solution with this?

In web 1.0, I use containers that group necessary controls for specific functions within a transaction flow, with transaction-level classes handling the data logic. I create containers programmatically upon request, for example when the user clicks on a tab located either on a page or on a master container (the master container approach does not work quite as well in Web 2.0 in my experience). This way, only some of the controls are loaded at any given time. This approach works very well in Web 1.0, but I have had much less success when trying to port (and largely re-write) one of my applications in Web 2.0.

One advantage of this approach, in addition to speeding-up things in Web 1.0, is to de-clutter the UI and focus the user on specific functions within the transaction flow.

Thanks for the Idea Mr. Louis.

however, there are time that I have to show up all necessary information specially when editing record.
What I am thinking now is to provide the user a locked screen showing a “wait progress” then close it one the UI is completely drawn.

I hope somebody can share their experience on doin this?

How many controls do you requiere to edit a record?

Well, that is complicated. There was a feature request to implement this, but xojo didnt listen and never implemented the feature, now that web 1.0 is dead, it will never happen :frowning:

The problem here is the lack of client side control, so, the way to do it in pure xojo is: User clicks something, this event is sent to server, server then answers to client ShowTheDialog and finaly the client shows the dialog.

This consumes bandwidth and the worst part is the delay, from half a second to several, the user can click other things in that time.

1 Like

7 textfield, 1 check box, 1popmenu.

That’s sad story.

Or maybe there are some genius here that can do the 3rd party who can provide client side control which will resolve this common issue.

7 textfield, 1 check box, 1popmenu

Well, that is not so many. Most of my containers have up to three times that number of controls, most often textfields, popupmenus, listboxes, and checkboxes. Labels on top of that to provide field captions and such.

I am at a loss to understand why you experience performance issues.

1 Like

That is really low, it should work really fast (unless you have 200 controls in the back hidding and showing)

Are you dinamically adding and destroying controls or you load all of them?

I use 3rd party “taylordesign” tab control to display each control container on every tab click.

I created 3 container control to hold all the ui control.

everytime I clicked that TAB, it took 3 to 5 seconds to show up each container control.

:frowning:

Is it possible that you have a lot of logic placed in the open or shown events of the controls? Depending on how complex or heavy that processing is, it could slow the rendering down significantly. I try to make the UI controls as dumb as possible and to keep the logic in methods or class methods that are executed upon request. Also, I tend to load common data in the application or in some cases the master container ahead of time. There are less database calls as a result and things speed up a bit as a result. In order to hide the delays, I load some general data at the login screen (such as general configuration data), and some more after login (login-dependent stuff).

I second Ivan’s comment. Pages or containers with many more controls than you describe are common in my applications. I rarely have UI related performance issues (in Web 1.0 that is! In Web 2.0, pages as you described can take several seconds to render, more even to be ready for processing)

Maybe a bug in the 3rd party control. Try to use a ContainerControl, you can aply styles to make it look like the tab body. And as @Louis_D says, keep the code simple, just hidding 2 containers and showing the other. For the Tabs, you can use buttons or a toolbar.

1 Like

Thanks for the idea MR. IVAN.

This really helps a lot.

Is it already slow in your debugger or on your final server? I have many controls and never encounter an annoying delay in the debugger, server depends on what I am running it on (usually rather low budget configurations, so I’m not too surprised :wink: ).

I definitely keep my opening and show events as slim as possible. But yes, for the time being I’m staying mainly with Xojo native stuff, for the simple reason that I’m assuming future changes will come, and I don’t want to optimize yet specifically for the current release.

I tried to run the app under debugging mode and deployed mode. The issue exist in both mode.

I will upload the screen capture here so that everybody can see it.

1 Like

This is the screen capture converted to GIF for your viewing

xojo_screenrecord

Was your app running locally or on a remote server when you captured that gif?

That defenitely looks slow.

1 Like

This is a good read why Xojo Web is very slow (and because there is no solution other than redoing the entire framework).

2 Likes

Good read like BMW blaming GM that they can’t build cars?

1 Like

Hi Hector, the video that I captured is running in debug mode. I also tried the build version but show the same results.

Looks like a reasonable number of controls. Have you trieed without the “tab control” yet?