topic: dynamic thumbnail gallery layout

[ashleydavis]

I have a photo gallery layout algorithm that I'd like to port from TypeScript to Roc.

It is capable of doing incremental layout (as new assets are downloaded in the background) which allows it to do the layout for 100k images without the user even noticing.

Live demo with 100k assets: https://photosphere-100k.codecapers.com.au

The TypeScript type signature looks like this:

export interface IGalleryItem {
    _id: string;
    width: number;
    height: number;
    thumbWidth?: number;
    thumbHeight?: number;
    aspectRatio?: number;
    // --snip--
}

export interface IGalleryRow {
    items: IGalleryItem[];
    offsetY: number;
    width: number;
    height: number;
    // --snip--
}

export interface IGalleryLayout {
    rows: IGalleryRow[];
    galleryHeight: number;
}

function computePartialLayout(layout: IGalleryLayout | undefined, items: IGalleryItem[], 
    galleryWidth: number, targetRowHeight: number): IGalleryLayout;

It will be interesting to benchmark the TypeScript code against the Roc code.

It would be nice to do the entire gallery frontend in Roc, but for the book it is possible to demonstrate the layout algorithm in code that is runnable from the CLI.

Here are some other ideas related to this that might also be worth considering:

• Virtual view port
  • Only showing the rows of the gallery that are visible (making it possible to render a gallery with 100k assets). Performance is key here, because we have to rerender as the user is scrolling through the gallery.
• Prioritized download queue
  • Thumbnails are queued for download to be displayed in the gallery.
  • There are two priorities:
    • High priority for thumbnails that should currently be on screen (we need to download and show these in the shortest possible time).
    • Low priority for thumbnails in the pages before and after the current page being rendered (these are the thumbnails that the user will scroll to next, so they don't need to be displayed immediately).
• Page-based loading of thumbnails
  • Loading individual thumbnails from AWS S3 is very slow.
  • To make a big set of thumbnails load quickly they are aggregated into a "page" containing 100 thumbnails. This means that one request replaces 100 when loading thumbnails. The "page" is packed on the backend (and cached in S3) and unpacked on the frontend.

[gvwilson]

This is cool, but is it one chapter or two? I.e., is the actual positioning of visible assets simple enough that the focus would be on the paging/download/etc.? The JS and Py versions each devote a chapter to row-and-column box layout, but maybe the layout itself here is simpler?

[ashleydavis]

Just one chapter and I'll only do one chapter myself. The related items could be for other chapters.

I just wanted to get a few ideas down just in case the first one wasn't enough.

[gvwilson]

@ashleydavis I've assigned this one to you - can you please create a subdirectory under the project root called gallery and put your work there as a standalone Roc project for now? Cheers - Greg

[ashleydavis]

Will do, first thing for me is to figure out how to get Roc to work. It doesn't work under Windows yet and it seems to hang on Ubuntu under WSL2.

[ashleydavis]

@rtfeldman @gvwilson I'm keen to get started but Roc doesn't run on Windows and there's a problem running it under WSL2.

I found an issue already logged and added my details to it:
roc-lang/roc#5887

[rtfeldman]

@ashleydavis Does the workaround Anton posted in that issue get it running? (That is, adding --linker=legacy to roc dev)

[ashleydavis]

Thanks @rtfeldman, but doesn't seem to have helped.

Getting this error now:

$ roc build --linker legacy main.roc
thread 'main' panicked at 'not yet implemented: gracefully handle `ld` failing to spawn.', crates/compiler/build/src/program.rs:1053:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I get a similar error for roc dev --linker legacy.

[ashleydavis]

I tried setting RUST_BACKTRACE=full for extra details, but not sure it helps:

$ roc build --linker legacy main.roc
thread 'main' panicked at 'not yet implemented: gracefully handle `ld` failing to spawn.', crates/compiler/build/src/program.rs:1053:30
stack backtrace:
   0:     0x562da85053b6 - <unknown>
   1:     0x562da784e2cf - <unknown>
   2:     0x562da8500b77 - <unknown>
   3:     0x562da85051c5 - <unknown>
   4:     0x562da8506963 - <unknown>
   5:     0x562da8506724 - <unknown>
   6:     0x562da8506e66 - <unknown>
   7:     0x562da8506d44 - <unknown>
   8:     0x562da85057b6 - <unknown>
   9:     0x562da8506af2 - <unknown>
  10:     0x562da774ae03 - <unknown>
  11:     0x562da7a52f9e - <unknown>
  12:     0x562da7a501dc - <unknown>
  13:     0x562da7b40b97 - <unknown>
  14:     0x562da7a1d0bb - <unknown>
  15:     0x562da7a12cf3 - <unknown>
  16:     0x562da7a12d13 - <unknown>
  17:     0x562da84f7f25 - <unknown>
  18:     0x562da7a1f7d5 - <unknown>
  19:     0x7f52ba741083 - __libc_start_main
  20:     0x562da77e21fe - <unknown>
  21:                0x0 - <unknown>

[Anton-4]

I suspect installing Ubuntu 22.04 (still under WSL) will be the easiest fix. The installation through the microsoft store works great.

[rtfeldman]

@ashleydavis Was the gracefully handle 'ld' failing to spawn error on normal Windows or WSL? That would be a strange error to see on Windows, because the legacy linker shouldn't be trying to spawn ld on Windows! 🤔

[ashleydavis]

I'm running under Ubuntu WSL2 under Windows.

[ashleydavis]

I've tried running it on my quite old MacBook Air.

But it seems like I'm missing something:

% roc dev
dyld[49262]: Library not loaded: '/usr/local/opt/z3/lib/libz3.4.12.dylib'
  Referenced from: '/Users/ashleydavis/Roc/roc_nightly-macos_x86_64-2024-03-18-14ba398/roc'
  Reason: tried: '/usr/local/opt/z3/lib/libz3.4.12.dylib' (no such file), '/usr/local/lib/libz3.4.12.dylib' (no such file), '/usr/lib/libz3.4.12.dylib' (no such file)
zsh: abort      roc dev

[Anton-4]

I think brew install z3 zstd should fix that (macos x64 getting started).

[ashleydavis]

Thanks @Anton-4 I did that and got a bit further.

But I seem to be getting the same kind of error now on my Mac as on Ubuntu (under WSL2 / Windows).

% roc build main.roc                
ld: library not found for -lSystem
thread 'main' panicked at 'not yet implemented: gracefully handle `ld` (or `zig` in the case of wasm with --optimize) returning exit code Some(1)', crates/compiler/build/src/program.rs:1064:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I also tried running roc dev and roc build --linker legacy main.roc.

Bear in mind that my Mac is quite old now and possibly @rtfeldman you don't want to support it anymore.

[Anton-4]

Can you try running:

$ export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
$ export LIBRARY_PATH="$LIBRARY_PATH:$SDKROOT/usr/lib"
$ roc build main.roc

[ashleydavis]

@Anton-4 I did that. I still get an error, but it looks a bit different now:

% roc build main.roc
ld: library not found for -lSystem
thread 'main' panicked at 'not yet implemented: gracefully handle ld (or zig in the case of wasm with --optimize) returning exit code Some(1)', crates/compiler/build/src/program.rs:1064:17
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

[Anton-4]

Brian Carroll has experienced this issue before, I've now asked if he was able to solve it.
Is using Ubuntu 22.04 on WSL not an (attractive) option for you?

[Anton-4]

Brian just confirmed he was not able to solve the issue on MacOS.

[ashleydavis]

@Anton-4 Success! (at least with the legacy linker)

I can move forward now, so thanks @Anton-4 and @rtfeldman for your help.

I'll document here what works and what doesn't work.

I've upgraded to Ubuntu 22.04 under WSL2:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

This works for me now:

roc build --linker legacy main.roc

Also this:

roc dev --linker legacy

Running the code produced by the legacy link works as expected.

Building normally is ok:

$ roc build main.roc
0 errors and 0 warnings found in 10334 ms
 while successfully building:

    main

But running the output of the normal build produces a seg fault:

$ ./main
Segmentation fault

Roc dev by itself hangs indefinitely:

$ roc dev

This is the code I'm running:

$ cat main.roc
app "hello"
    packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.8.1/x8URkvfyi9I0QhmVG98roKBUs_AZRkLFwFJVJ3942YA.tar.br" }
    imports [pf.Stdout]
    provides [main] to pf

main =
    Stdout.line "I'm a Roc application!"

[Anton-4]

Thanks for sticking with us @ashleydavis :)
I was unable to reproduce the hanging or the segmentation fault on WSL2, Ubuntu 22.04.4 LTS on Windows 11.
Can you share the output of:

1. roc version
2. uname -a
3. lscpu