I am finding Xojo Cloud to be way too slow. I have a lot of optimizing to do still but I am not too encouraged at this point. Certain things just don’t work at all (e.g., keypress event; takes forever to register in the app, especially on Internet Explorer) and I’ll have to find alternative methods or eliminate dynamic aspects of pages for the entire app.
I think one page is causing a lot of problems because it is using the MouseMove event. I’ll have to take that out.
Not sure what to do next. I tried restarting the server. Didn’t help.
Any suggestions (software, control panels, things to avoid using like mousemove event, etc) on how to optimize would be much appreciated.
Yeah, don’t do that. Essentially what you’re doing is causing the event to get passed up to the server EVERY time you move the mouse. All events are handled by the server. All you’re doing is overloading the buffer which will slow your app down big time.
I wish those events simply didn’t exist in Web Edition. They cause more grief than they’re worth.
We have a moderate sized client app (couple of hundred containers and pages) working on Xojo Cloud and not noticing a slowdown. So it can be done.
I suspect you’re using other events that might make sense in desktop apps but not in Web apps. Without seeing it in more detail it’s hard to say.
Would a WebAnimation work okay? I have one page that requires objects to be turned on briefly and the timing is critical. Using a timer doesn’t work at all (namely, the time that the object is shown isn’t even close to the target time when using timer). Is there any way to run the timer on the client PC?
Also, need some way to monitor the server. Is there anything that can be installed? Or do we have to create our own apps in Xojo to monitor the server?
The web animation happens entirely client-side. MouseMove and KeyPressed events each require a round trip to the server and back. Over time, we will make things more and more efficient (where we can) to avoid these extra round trips. For example, the Paint event of the Canvas control is well-optimized. It does not render the picture on the server and send it to the client. Instead, it sends the graphics commands the client needs to render the picture client-side. Even better, from one paint event to the next, it determines what the differences are and only sends the graphics commands that have changed. We have lots of ideas for ways to make additional improvements like this in future releases so you can focus on your app and not think about the framework or the fact that there could be thousands and thousands of miles between the server and the client.
Perfect! I was hoping for an answer like this. It would be nice if it were easy to tell which stuff runs on client vs. server.
Maybe I can make this work after all. Pages are still a little laggy (but tolerable) and HTML formatting is sometimes not correct (e.g. line spacing) but all in all I think this is all fixable stuff.
That’s an interesting point, wonder if there’s anything that can be done in the docs to highlight what event involves a round trip to the server. Would make life a bit easier. I’ll collar Paul at XDC. (Sorry Paul )
Is there a way to ‘fake it’ by have the server create the still images on the server (quickly), turn them into a movie (quickly), then pass the movie to an HTML Viewer to display (slowly)?
David - I don’t know but if you figure it out let me know. That would be useful.
I solved my slowness issues by using webanimator and webcanvas. I still have a lot to learn about handling pictures but at least I have a functioning app now. Even so, some pages still load slowly and there are random, intermittent problems on pages where jpgs are loaded. I think I need to add a refresh button to every page (the browser refresh just starts over).
)