You seem to have good progress toward a workable solution already, but
FWIW here's how I handled a similar case:
I was building a bespoke authoring system which included an image
library. There were some 2600 images in the collection when we started,
and at the rate of new additions we didn't expect that to exceed 5,000
through the anticipated lifecycle of the system.
With such relatively modest constraints, when it came to making the list
view with thumbnails and image file metadata, I sent all of them over at
once. :)
But the key is *how*:
On the server, when an image is added to the collection a thumbnail is
generated along with it.
But rather than storing the thumbnail as a separate file, we add that
image data to an array keyed by file name. Then the array is encoded,
and the resulting LSON written to disk.
When the user opens the image library list view, that LSON file is
downloaded in one HTTP GET, deserialized, and stored in a variable where
it's used to populate the DataGrid as needed.
Of course that makes populating the DG satisfyingly instantaneous, but
at what download cost?
Turns out it's pretty minor in our case. 2600 thumbnails about an inch
square, compressed with a JPEG quality of about 80%, take up very little
space. And at 1", differences in JPEG compression quality make far less
difference to the eye than they do to the resulting size.
All in all, IIRC the download time was just a couple seconds, since the
whole LSON archive was just about 1MB - and that was on the crappy
"U-Verse" connection I had at the time, slower than even my 4G phone.
One thing worth keeping in mind with remote storage is the impact of
multiple HTTP connections. HTTP is a great protocol, far leaner than
most give it credit for. But its overhead is not zero, and TCP in
general carries a certain overhead, and even just the connection latency
adds up too.
With 2600 images, that could have been 2600 GET requests, with all the
overhead incumbent in each.
But trading off a barely noticeable load time to reduce 2600 requests to
just one paid off handsomely in the smooth-flowing user experience of
traversing the image collection.
Indeed, at the same company in a separate department a team of Java
developers were tasked with a similar UI challenge. Not only was the
implementation much more expensive, but they didn't batch requests like
I did. Authors who've used both cite the one I delivered as a more
productive experience. Bonus that it was delivered at 1/4 the dev cost,
and ran on twice as many platforms. :)
--
Richard Gaskin
Fourth World Systems
Dan Friedman wrote:
> Richard,
>
> Probably not over a couple thousand. The images are square -- they
> need to be resized to the DG template image size, but not scaled (H
> vs W).
>
> On 2/21/22, 12:14 PM, Richard Gaskin wrote:
>
>> How many images?
>>
>>
>> Dan Friedman wrote:
>>> Does anyone have any answers to the issue of loading a long list
>>> with images so that it loads images "as needed" like a webpage does.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
