My question is the same as the posts title. Do invisible controls use system resources? In other words, would a page of invisible controls use the same amount of system resources as a page full of visible controls?
Since the controls are invisible, doesn’t that mean that they don’t get drawn? And if they don’t get drawn, doesn’t that mean that they consume less cpu cycles?
Indeed you save a bit of time in displaying time. But under normal circumstances that takes very little resources. Otherwise an invisible control takes the same amount of memory, and CPU for events if called.
In normal development in xojo the resources needed by controls is rarely a problem.
Or in other words: nothing to worry about
While i usually disable and make them invisible just in case believe invisible controls DO NOT fire events in response to anything the end user can do directly.
[quote=110744:@Karen Atkocius]While i usually disable and make them invisible just in case believe invisible controls DO NOT fire events in response to anything the end user can do directly.
Usually not, but timers do fire, controls content can be updated and methods inside can be called. I am working on an app that precisely updates the content of an invisible window so it is ready when the user decides to show it.
Is the same true for a web app? I am thinking that Xojo web apps are constantly talking between client and server. If you had 20 invisible labels (or something similar) on a page would each of these be polling back to the server to see if anything had changed or any other events? If so then this would be consuming more bandwidth and resources on the client and server side.
It would not make much sense that an invisible UI control polls the connection. The back and forth between the app and the client is necessary only for visible objects. However, some invisible controls like WebTimers which are client based may create events that poll the server. Unless the web labels specifically created events that would require client server communication, I would not worry too much about that, like Christian says.
No Nathan, this does not work this way.
Please take a look at the developers tools in you browser and see the network requests between server/client.
Michel / Maurizio
Whilst I understand what you are saying I am not sure that it is correct because the label has to talk to the server to know if it has been made visible so their must be some communication going on. Not sure if you have ever looked at the framework.js that Xojo uses to do all the communication but their is room for improvement with regard to controls doing things when they dont need to, I have raised this in other posts where events are still checked back and forward between client and server even when you dont use the event on a control. I understand that it will be a low overhead but something that needs to be considered when using low bandwidth high latency connections e.g. mobile network in congested locations.
[quote=110938:@Maurizio Rossi]No Nathan, this does not work this way.
Please take a look at the developers tools in you browser and see the network requests between server/client.[/quote]
I have used Firebug in the past and have seen that it does not show any bandwidth / communication going on when clearly their is something going on because I have used a packet sniffer on another PC looking at communication between my laptop and the server (on the same network) and data is flowing back and forward between the client and the Xojo app so i wouldnt take everything you see in Firebug as the whole truth.
As long as the control is not visible, there is no reason for it to be sent to the client in the first place. Unless I am mistaken, you have actually two sets of code :
- Xojo code which runs as a Linux program on the server
- JS code sent by the app to the browser on an ‘as needed’ basis.
As far as I understand, when a control is not visible, it does take memory and possibly some CPU, but is not sent to the browser, so there is no JS object that needs to talk to the server. In effect when you hide a label, it is destroyed in the browser DOM.
I have not verified for a Xojo app, but that is the way it works within a desktop HTMLViewer : not displayed = does not exist. At least I verified that with buttons.
in Firefox under the menu “Developer tools” there are a lot of functionality you can try to see what it is going on between client and server.
The same tools are available in Chrome and IE.
If you are concerned about resource usage and network bandwidth I suggest you to use webcontainers.
Using webcontainers you can dynamically build your page with only the elements really needed.
I use them regulary: they are useful and not so difficult to master as others developers are reporting.
Michel, ah that makes sense, my JS and DOM are not great and I hadnt realised that the actual invisible control is not in the DOM until it is needed and then passed to the browser, that is very clever and useful to know.
Maurizio, I always forget about Dev Tools in FF as I am so used to using Firebug, thanks for the reminder. In my apps I tend to use webpages rather than webcontainers and their seems to be a mixed view on if (if either) are better. Do you think web containers are better than having lots of pages from a resource point of view?
In terms of resources, chances are the two solutions are probably pretty equivalent. Too bad there seems to be no easy way to know how much resources an app is using which would allow benchmarks.
In terms of design and maintenance, the page-based model is probably a lot easier. But yet again, for all intents and purposes, containers can be construed as sort of a mini-pages …
Starting from multiple pages now I’m only using containers created dynamically in a single page.
For me containers are more effective than pages: you can change parts of your page without loading a complete new page.
In terms of design and maintenance, the container-based model it is more object oriented.
You build pages using sets of reusable independent features that are more simple to maintain when compared to a complete page with many features glued together at the design stage.
It is up to you to try and decide what is better.
Programming offers so many alternate paths…