Releases: SmilyOrg/photofield
v0.4.2
v0.4.1
v0.4.0
Changelog
- db6cf64 Add scene load progress spinner
- 22b1105 Avoid waiting for scene unnecessarily
- 058dc38 Better image/video variant handling
- f0e4560 Fix jumpy scroll position in large collections
- 026d28e Fix window resizing
- d7bed01 Limit minimum tiled image size
- 5d1183e Merge pull request #10 from SmilyOrg/large-collections
- ca1d796 Quick regionSource nil panic fix
- 08d3b39 Skip drawing tiny text
- 135d414 Use same tile size for region menu
- 96c7730 Various profile driven optimization
What's Changed
Full Changelog: v0.3.3...v0.4.0
Contributors
Assets 10
v0.3.3
v0.3.2
Smoother scrolling on slow devices
Previously the whole canvas was redrawn every time while scrolling. Fast devices like PCs had no problem with this, but slower devices, like phones, tablets and TVs were not able to keep up the redraws while scrolling leading to a laggy experience sometimes nearing slideshow levels. With this release the canvas is scrolled natively by the browser, which can be a lot smoother. 🏃♀️
Technical Details
Since the canvas is virtual, the native scrolling needs to be combined with redrawing so that the photos never "scroll out of view". If the device is slow and is unable to keep up with the redraws, this now presents itself as "white space" where the redraw has not happened yet. This seems like a better tradeoff as it feels a lot better to have a smooth scroll with some edge artifacts than an always-stable, but laggy scrolling.
These artifacts could be overcome by overdrawing at the edges, so that there is some wiggle room before a redraw needs to happen. This is not implemented yet as a larger canvas can also lead to slower redraws in the first place, so a balance would need to be found.
Changelog
- 6d65578 Add native scrolling
v0.3.1
Make it Actually Work™
v0.3.0 had a few bugs making it hard to get started with the single binary release.
What's Changed
- Allow use of environment variable to specify a custom server address by @luusl in #7
- Fix app refusing to start if you don't already have a database c3ff254
- Fix app showing a blank white screen in browser (in some cases, especially Windows) 69d5aeb
New Contributors
Full Changelog: v0.3.0...v0.3.1
Contributors
Assets 10
v0.3.0
More Efficient Database
This release should be functionally equivalent to v0.2.1, however it reorganizes database storage and processing so that it both takes less space and runs faster (especially scene creation on slow disks).
As an example, in v0.2.1, it takes up 193MiB for my database of ~540k photos. In v0.3.0 the same database with the same data takes up 74MiB.
More Detail
Both sizes are after vacuuming for a more accurate comparison. You can run a vacuum as a maintenance task through the app itself now too. Ideally in the future this would be automatic, but for now you can run it now and then if you'd like to reclaim some space after adding/removing a lot of files.
Even More Detail
Previously all the file paths were stored as absolute paths, which worked pretty well, but if you have a lot of files, it can lead to a lot of duplication as the same long path is stored for each file. This release de-duplicates all the directories into a separate table, so each file only references this table. It almost sounds like I'm reimplementing file systems here, but I swear it makes sense 😅
This leads to only the file names and a reference to a directory having to be stored. With the above real-world collection of 540k photos, they are only part of ~4600 directories, leading to the big storage savings. This complicates the queries a bit, but SQLite does a good job at executing them.
Due to internal reworking, file paths are also no longer needed when listing / opening a collection (album), so the query can just filter to a few specific directory ids, returning the file metadata in order. With the right indexes this can be pretty fast and efficient. At least that's the idea 😄
Changelog
- 0f5278b Optimize file paths
v0.2.1
v0.2.0
Embedded JPEG thumbnails
Embedded JPEG thumbnails are now supported. Extracting them is slower than loading pregenerated thumbnails already on disk, but way faster than loading the original, so it's a nice middle ground if you don't already have thumbnails.
Debug Modes
Additionally, the two debug modes supported by the API are now accessible again. They exist to more easily debug how and when the thumbnails are being used.
Debug Overdraw
Shows how close to "perfect" is the thumbnail / image being loaded.
More red 👉 too high resolution / wasted loaded pixels / slow loading
More blue 👉 not enough resolution / blurry display
Using only embedded JPEG thumbnails shows that when the original images has to be used, it is way too high of a resolution for the currently displayed size, so it's slow.
debug.overdraw.mp4
Debug Thumbnails
Shows the resolution of the thumbnail / image being used, the "distance" from the ideal resolution for the currently displayed size and the name of the thumbnail (or original for the original photo).
debug.thumbnails.mp4
Changelog
- e95e1c3 Merge pull request #5 from SmilyOrg/embedded
- 9aa66f8 Support embedded jpeg thumbs + fix debug modes
Docker images
docker pull ghcr.io/smilyorg/photofield:v0.2.0docker pull ghcr.io/smilyorg/photofield:v0docker pull ghcr.io/smilyorg/photofield:v0.2