Speed up image loading

I would like to give credit to Daniel Taylor for making me aware of this.

If you use the URL option rather than Xojos own internal images on imgView you will find the images load much quicker using the URL option. The difference is so visible I have made the choice not to use the Xojo internal images any more with my web project.

Once I started to use a third party web server for the images I decided to use IIS on Windows as it can be tweaked to disable session and cookies, setting the cache a long way in to the future and disabled all other file types accept JPG and PNG. Ideally I would like to use a more lightweight server but at the moment their does not appear to be one that can do all the things like IIS can. It might be interesting to write a HTTP server in Xojo specifically for images and keep all the images in memory and optimise it specifically for this purpose to tweak out a little more speed. Also if someone requests a file type that is not known then depending on the domain name used it would redirect to the main site rather than the image server.

A big thanks to Daniel for teaching me about the URL option in Xojo.

This is something I will definitely implement into my webedition of the SimDesignerCanvas as speed is important. … especially in graphics intensive functions :slight_smile:

Thanks for sharing this tidbit!

You might also want to take a look at what WCC does with the image loader function which allows you to preload images before they are used. I have also implemented this as well so that images are frontloaded in the app but it means that when the images are displayed to the user they are very very fast as it is getting them from browser cache rather than a server that could be a long way away. What Daniel has done is very slick in that you call a method with the URLs you want cached and then you go off and do something else (even on another web page) and the images continue to load in the background so what I have done is preload the first menu the user sees before the menu is displayed and then I load the images for the rest of the site in the background in an order which I a fairly sure they will use the site in so these are normally loaded by the time they select the menu option. The least used pages are loaded last. It works really well and makes it much cleaner for the user.

That’s not surprising if you’re using cgi. With the direct URL, downloading the image only requires one app, Apache. If you use a WebPicture (or WebFile) it uses three, Apache, Perl and your app.

I also suggest Abyss WebServer: http://www.aprelium.com/abyssws/

It works perfectly on Windows. It is very light and fast, secure, support is very good. Many safety are handled automatically. Obviously, this is not as powerful as Apache or Nginx, but it is a very good compromise for Xojo. Above all, they have adapted to it works well as a reverse proxy with Xojo. it is rare to have a company that adapts its product to suit your needs! you will find discussions on Abyss / reverse proxy in the archives of realbasic NUG.

experience, the CGI is disappointing, it is too slow and too limited to Xojo.

Many of us expect full support of reverse proxy:

(Xojo: Account Login)>]<https://xojo.com/issue/23891>

For images, Xojo can not cache them apparently:

(Xojo: Account Login)>]<https://xojo.com/issue/32954>

Nathan - thank you very much for the mention. Happy to help.

The control Nathan is referring to is WebImageLoaderTD. The demo on my site isn’t all that impressive. I just load a few photos with a progress bar and then you can click between them without waiting. But if you structure your site the way Nathan has, use an external image server, and take advantage of this control you can really improve the end user experience on an image heavy site. The control can load external URLs and WebPictures and notifies you via events as each image is loaded and ready to go.

I would agree that the best way to run Xojo web is stand alone with a proxy as necessary for SSL and load balancing. Stand alone was even more impressive with WebSockets (can’t wait for that to be restored). Xojo can only do so much with CGI because requests have to go through the Perl applet so that the main web server is not constantly starting/quitting the main app which would be far worse.

If you are running CGI, make sure you are running mod_perl or something like it. Out of the box Apache will launch a Perl instance for each request which is awful from a performance standpoint. mod_perl is persistent and much, much faster.

thank you Nathan and Daniel, nice feature!

beware, however, limited memory (and the limited cache) on mobile. I guess if WCC could not preloaded images before, the image is downloaded normally when it should be displayed?

yes! readers, please vote!

(Xojo: Account Login)>]<https://xojo.com/issue/18354>

[quote=87773:@olivier vidal]thank you Nathan and Daniel, nice feature!

beware, however, limited memory (and the limited cache) on mobile. I guess if WCC could not preloaded images before, the image is downloaded normally when it should be displayed?[/quote]

Good point on mobile. You don’t want to download 100 MB of images to an iPhone.

If an image load were to fail for any reason I believe the browser would make another attempt upon display. If the image is displayed before the load is complete, the browser just fills it in once complete. If pre-loading pushes something else outside of a limited cache, the browser will just request it again when it needs it.

Just to clarify, I am running the web app as a standlone (on Windows) and NOT cgi and the image loading speed is not great and much better using a separate HTTP server.

What you will also find on desktop and mobiles is that the layout renders quicker when you use a URL instead, I think this has something to do with the fact that the browser already has an idea of the image size etc so the page is rendered correctly first pass whereas if you use the internal images with Xojo you can see a flicker as the browser renders the page.

I’ve seen a performance boost from using an external image server with stand alone as well. In fairness to Xojo, having two server apps splitting the content likely makes better use of physical server resources. Under the hood Apache and IIS spawn worker processes for this reason. That’s not as simple for Xojo because of the shared memory space and context, though at some point I imagine Xojo could be made to spawn worker processes for static content.

I have a little bit of a mad idea which I am going to play with but I am thinking that it might be possible to create an HTTP server within my web app that runs on a specific port with the sole purpose of serving up images which it will read from a folder and store them in memory for delivery. If it uses multiple threads then it might be quicker than Xojo itself or it may be that it will have to be a totally standalone http server.

Daniel, out of interest does your WebImageLoaderTD take into account images that have already been cached by the browser? So if the user has visited the site before and your WebImageLoaderTD preloads the images, when the user visits the site later and the images have already been downloaded does it know and not download them again because in my tests I am not convinced that it does but not 100% sure.

If the image at the URL is already in the browser’s cache it will not be re-downloaded. The completion event will still fire.

Perfect, thanks.

I doubt you’ll see a speed improvement using threads in your web app. Because Xojo is cooperatively threaded your threads will merely compete with the threads handling the web framework. I believe Picture objects are already stored in memory, and using an external server is faster then using Pictures in your project.

Can’t say for a separate Xojo app. A lot of work has gone into optimizing the various web servers out there. They use multiple processes and/or preemptive threads, memory and disk caching techniques, and may have optimized interactions with the OS network stack. Not saying you couldn’t build a fast server in Xojo, just saying it might be a lot of work.

I did think it might be the case, thanks for your comments and thoughts.

Regarding image caches, what we finally decided to do in xojo was to put a modification date equal to the app build date for the framework stuff and each WebFile and WebPicture has an internal modification date so our framework is able to give the correct response if something changes. That being said, Daniel is correct in that because we run cooperatively on a single core, serving other resources can slow things down considerably.