I have 16 thumbs that I am displaying in a listbox. When the user clicks a thumb I am using the following code to load and display the full size imag…
dim f as FolderItem = New FolderItem( docPath+selected.ToText+".jpg", folderitem.PathTypeNative)
HomeImageViewer.Picture = ResizeToFit(Picture.open(f),HomeImageViewer.Width,HomeImageViewer.height)
Is that the best and most efficient way to do it?
This is a rewrite of an iOS app that I wrote a while ago in xCode. The iOS app is noticebly faster than Xojo downloading and displaying the full size images.
I did try to load all the full size imagas into an array when the thumbs were loaded into the thumbs listbox. So then my code looked likethis…
HomeImageViewer.Picture = ResizeToFit(pictures(row),HomeImageViewer.Width,HomeImageViewer.height)
But that did not make any difference. Are arrays in fact stored on the server? I am truly showing my ignorance here.
All of the Xojo code, classes, etc are stored in the binary that is running on the server itself with the results of those operations being sent to the clients browser.
Does HomeImageViewer change in size at all? If not, you can save a little response time by storing the full size pictures at the right size.
Its important to note that because the binary resides on the server, theres an extra round trip when loading pictures this way.
- Browser: User clicks row
- Server: ImageViewer class gets new picture, url sent to browser
- Browser: gets url and requests picture
- Server: sends picture
- Browser: receives picture & displays it.
With your iOS app, because the binary code resides on the device, the request probably looks more like:
0. Phone: user touches row
0. Phone: requests url
0. Server: sends picture
0. Phone: receives picture, resizes and displays it.
Its a subtle difference but an extra round trip to the server can be a noticeable difference.
I have zero experience with the Web target but I am quite sure that any code you write in Xojo runs on the server (backend), whereas the objects you assign may pass their data to the frontend.
So, if you pre-size the image before assigning it to an object, then the object will most probably only transfer the smaller version of the images, which, of course, gets then transferred faster than a larger image.
(later)
Oh, now, after reading Greg’s answer, I realize that I didn’t fully understand what you were asking. Nevermind my reply here, then.
Also, when you resize the img, keep in mind that the frontend may be using High-Res screens (2x or 3x). So, if you plan to show a 16x16 thumb, make it at least 32x32 pixels in size so that it still shows in a reasonably high res on the screen. Ideally, you’d create images for 1x, 2x and 3x sizes and assign them to the same Picture object. I hope Xojo’s code is smart enough to then only transfer the “correct” size fitting the frontend screen, so that it doesn’t transfer more than necessary but enough to make the img appear crisp. Greg can probably confirm this.
In terms of most efficient way, if the sizes are the same on every persons browser:
0. only convert the pictures once
0. Make a WebPicture for each one, with the data stored on disk if theres a memory concern.
0. Set the WebPictures session property set to Nil if the images are shared with all users
0. Store the WebPicture objects in a dictionary or array so you can quickly retrieve them later.
When a user clicks a row, see if the picture has already been loaded, if not, follow the steps above. Then look up the image and then set the ImageViews Picture property to the WebPicture.
Great stuff!
I think I should give a bit more background on what I am doing. There are 250gb of images taken in series of 16 images during patient appointments over several years of a patient’s treatment, one series per appointment. Images can be many mega bytes in size, stored to disk directly from a camera. This historical data is viewed on the iPad during each patient visit.
To improve efficiency over the network, the database server maintains, on a daily basis, a “web buffer” folder. It creates copies in the buffer folder of those image series for patients with completed appointments 1 month prior to the current day and scheduled 6 months into the future. A thumbnail of each image is created as well as a “full size” copy of the image. The thumbnails are no more than 25kb so load in the browser almost instantly. The full size images when copied to the buffer folder are reduced to less than 1mb with sizes that hover around 900X700 some much smaller depending on the type of picture.
The WebImageViewer is designed for viewing on a 10.5 iPad with a preset size of 994x583. The resizing of the full image for the buffer folder is primarily done just to insure that the image is displayed proportionally when contained within the WebImageViewer in the browser.
So to be clear I am not using the thumbnail to view the “full size” image. I am displaying a seperate picture file pre sized by the database at the server for subsequent viewing in a browser on an iPad.
When I tested using a picture array to preload all the full size images in the requested series, I tested with and without the resizing to fit code and in all scenarios I continued to see the same speed difference between the iOS app and the Xojo webapp.
@Greg O’Lone I think your explanation of the 2 round trips to the server explains the difference in speed, but I am having a hard time wrapping my head around it. If I understand what you are saying, the folderitem is created and the WebImageViewer.Picture subsequently loaded all on the server. Then Xojo sends the URL of the loaded WebImageViewer to the browser which in turn sends a request back to the server for the WebImageViewer.Picture.
I am thinking then that my code is in fact a valid approach. I should not expect to see the same performance as one would expect from an iOS app.
If anyone is wondering why I am so conerned with the difference in speed. Even though still very usable, I will still have to explaiin to my client why with Xojo it is noticeably slower to display the images than with the iPad app I am proposing to replace.
Keep in mind when you are explaining this that the issue is more the fact that you are moving to a web based one than the fact that you are using Xojo. Any web app would probably have this same kind of round trip issue.
[quote]@Greg O’Lone Any web app would probably have this same kind of round trip issue[/quote].
Good point.
Again, to anyone tht is interested, Xojo is like a b reath of fresh air compared to developing and maintaining an iOS app. I dreaded the hoops I had to go through each time I had to add a feature or fix a bug in the iOS app. I now have over 50% of the features provided by the iOS app up and running in the Xojo web app. What took me months to complete in xCode took less than 2 weeks with Xojo and I can instantly deploy updates any time I want, no more waiting on Apple to give the app it’s blessing. What is amazing to me is that on the iPad with the App added to the home screen, the web app looks and feels nearly identical to the iOS app.
I do have one problem with the app on the home screen, however. It will not run in the background. If you leave Safari for any reason, when you come back to Safari it does an immediate relaunch of the app.