VR Gallery 2.16.2 - Years and Months, fixed

Browsing by year and month works properly again: going back to Days after Years shows your photos, not the year cards.

• Years and Months: the year cards no longer stay on screen under the Days button, the timeline rail no longer runs into an error at these levels, and the rail and the ordinary scroll bar are never shown side by side.
• Update check: asks the project's current GitHub address (the account was renamed).
• For screenshots: tools/make_demo.py, which builds the made-up library behind the README and website pictures, now also hides who took each photo, never invents a name that somebody in the library really has, renames albums and hand-named files, and refuses a library with a column it does not know.

Download VRGallery-Setup.zip, unzip it and run Install VR Gallery.cmd (or start VRGallery\VRGallery.exe from the folder). Windows 10 or 11, 64-bit.

VR Gallery 2.16.1 - Home and a Windows 95 look

VR Gallery opens on a new Home page and can wear a Windows 95 look; everything since 2.0.0 in one release.

• Home: opens on this evening, this day in earlier years and the worlds you have been to lately, and knows when you are in VRChat.
• Where you are, in the title bar: while VRChat runs, a pill says which world you are in, for how long and how many photos so far; afterwards, where you were last.
• Windows 95 look (Settings > Appearance): grey 3D panels, a navy caption, the navigation as a folder tree, Microsoft Sans Serif.
• Photos: eight shots of one pose fold into one tile; the day gets a spine; photos drag out of the grid to Explorer or Discord; the photographer and the instance are read from the photo itself.
• Tagging: the tag box comes up with the name already picked.
• Window: a second ground (Midnight or Ember) in Settings, glass that really blurs, snapping to the screen edges, a compact camera icon.
• Many smaller fixes: the grid no longer jumps back to the top, faster pages, crisper drawing.

Download VRGallery-Setup.zip, unzip it and run Install VR Gallery.cmd (or start VRGallery\VRGallery.exe from the folder). Windows 10 or 11, 64-bit.

VR Gallery 2.0.0

VRChronicle is now VR Gallery, with Erik's logo as the app's name and icon.

Your library moves itself

%LOCALAPPDATA%\VRChronicle becomes \VRGallery and vrchronicle.db becomes vrgallery.db on first launch — the WAL and SHM files travel with it, or sqlite calls the database damaged. It only ever moves when there is nothing under the new name, so a library that already belongs to the new name is never touched.

Verified against a real 47 MB library: 1715 photos, 58 sessions, 544 people, 347 in-frame tags and 1 album all still there afterwards.

A library opened with --data-dir adopts a legacy database in place instead, since the folder move deliberately only touches the real one. Old XMP sidecars are still recognised as this app's own work, rather than being treated as somebody else's file and copied aside.

The icon carries two drawings

The logo has "VR GALLERY" set into it, which is unreadable mush at 16 px. So the .ico holds different artwork per size: 256 and 128 keep the full logo, 64 down to 16 get the mark alone — the camera on the logo's teal-to-blue gradient, in a rounded square with its black edge.

tools/make_icon.py builds it, measuring the camera's bounds and the gradient's endpoints out of the artwork rather than hard-coding them. Pillow's own ICO writer takes one image and rescales it, so the container is written by hand.

Naming

Display name and folder name are now separate: VR Gallery for anything a person reads, VRGallery for folders, files and ids. The shortcut and the window say VR Gallery; the executable, the data folder and the installer say VRGallery.

The repository moved to fgs8z2n9qh-tech/VRGallery — GitHub redirects the old links.

A test-hygiene fix that fell out of this

Database() and Config() both call ensure_dirs(), so any test that forgot to redirect them created and wrote into the real library folder. A comment in conftest claimed this never happened. It did — and it left behind an empty VRGallery folder that would have blocked the migration of a real library. The comment is now an autouse fixture that points the whole run at a temp folder.

Tests 113 → 117, covering both directions of the folder migration and both directions of the in-place adoption.

VRChronicle 1.10.2

1.10.1 raised the frame rate without making a frame cheap enough to hit it, so nothing felt different.

This time I profiled instead of guessing — and two of my three guesses were wrong. The floating panels were not stopping Qt from scrolling cheaply (1.5 ms), and the fade-in's viewport refresh was not causing a repaint storm (0.4 ms).

What actually cost the money

• Every tile set an antialiased rounded clip path before painting — including tiles whose cached pixmap is already rounded. That drops Qt's raster engine onto its slow route, and a scrolling frame pays for it once per visible tile. Skipping it where the tile has settled: 9.33 ms → 7.03 ms.
• The clip path was built for every tile whether or not anything clipped it. Built on demand: 7.03 ms → ~6 ms.

Together with 1.10.1's cached backdrop, a whole scroll frame is down from 16.1 ms to 8.32 ms — the budget now fits 120 Hz where before it did not fit 60.

What I am not claiming

A number on your machine. These are measured on the headless platform, which composites differently from Windows, and they measure painting work rather than frames actually delivered.

A test now counts how many tiles took the fast path and fails if the slow one wins — this is exactly the kind of win that gets undone by accident.

VRChronicle 1.10.1

Scroll at the display's rate

Raising the tick rate on its own would not have helped, and would have made the glide shorter rather than smoother: the easing moved a fixed share of the remaining distance per tick, so ticking three times as often simply arrived three times sooner.

It is time-based now — one exponential with an 85 ms constant — so 180 frames a second means 180 steps across the same span. The position is kept as a float as well: at high rates the per-frame move is under a pixel, and integer rounding turned it straight back into a stutter.

The timer runs at the screen's own refresh rate instead of a hard 16 ms, and re-reads it when a scroll starts, since a window can move between monitors. This machine's main display reports 180 Hz — a 5.6 ms frame, being missed by a factor of three.

Then the frame itself

Measured, not guessed:

• The frosted header re-grabbed and re-blurred its backdrop on every repaint: 4.03 ms. Cached with a 33 ms life it is 1.05 ms. A backdrop blurred this hard does not read as stale at 30 samples a second.
• Every grid tile re-did its rounded clip and re-scaled its thumbnail on every frame. Tiles are pre-rendered per cell size and blitted now: 10.85 ms → 9.33 ms for the whole grid, 14%.

About 4.5 ms per frame of real work removed.

What that comes to in actual frames per second I cannot honestly claim from here: the headless platform used for measuring composites differently from Windows, and the numbers above are the painting work, not the frame rate. It should feel better — tell me if it does not.

Tests 112 → 113.

VRChronicle 1.10.0

The wheel glides instead of stepping

A wheel notch moved the scrollbar by a fixed number of pixels in one go, which on a wall of photographs reads as a stutter rather than as scrolling.

Notches now accumulate into a target and a 60 fps timer eases the bar towards it — a single notch takes about twenty frames, and a fast flick glides to a stop instead of arriving in jumps. It is on the photo grid and on every card page.

Ctrl+wheel still zooms: the filter hands that gesture straight back, and so is a horizontal wheel.

Two things worth writing down

The filter outlives its view during teardown — shiboken raises "internal C++ object already deleted" from inside eventFilter — so both the filter and the timer check for that and stand down rather than taking the app with them.

Scrolling now repaints the frosted header every frame, so I measured it before shipping: the backdrop sample and blur cost 1.3 ms, the whole header repaint 2.3 ms, against a 16.7 ms budget at 60 fps.

The test drives a real wheel event and then walks the animation by hand, asserting it takes more than four steps, only moves one way, decelerates, and lands exactly on the target.

Tests 111 → 112.

VRChronicle 1.9.0

All — one continuous sheet

A fourth level next to Years / Months / Days: no day headings at all, square tiles with a 2 px gap, sized so the row divides exactly, edge to edge. The library as one object rather than as a run of days.

The pinned day header stands down in this mode, since there are no days to pin.

The header folds away as you scroll

Scroll past the first screenful and the page title and its subtitle fade out and give up their room; the toolbar shrinks to just its controls. Scrolling back to the top brings them out again. Now that the grid runs underneath the bar, that band is worth reclaiming.

What the grid leaves free at the top deliberately does not follow the header down: the spacer row keeps the open height, or it would resize under the content and the whole library would jump while you scrolled. Only the things that sit under the bar track its current height.

The collapsed height is measured from the tallest control plus its padding. Guessing it as "a bit less than the open one" cut the search box and the pills in half, which is exactly what the first attempt did.

Tests 110 → 111.

VRChronicle 1.8.2

The pinned day header looked disproportionate — and it was shaped like the wrong kind of thing.

1.8.1 gave it the same rounded, inset card shape as the floating toolbar above it, for consistency. That was the mistake: they are not the same kind of thing. The toolbar floats over the library; the pinned day is the grid's own day header, frozen in place.

Shaped as a card it needed card padding, which put its text 21 px to the right of where the grid draws that very row — measured, not guessed — so the text jumped sideways the moment a day pinned. Its text was also bottom-aligned inside a rounded box, left over from mimicking a row that has photos directly beneath it, which is what made it look bottom-heavy.

It is a plain full-width strip again, with the grid's own left inset and a hairline under it, and the text vertically centred. The test now measures the grid's day-header position and asserts the pinned copy matches, so the two cannot drift apart again.

VRChronicle 1.8.1

1.8.0's glass header looked angular and lay across the scrollbar. Both right.

It spanned the page as a hard-edged rectangle. It is a rounded floating card now, bound to the viewport rather than the page, so the scrollbar and the timeline rail are both clear of it. The pinned day header below it got the same shape and inset — two bars of different widths stacked looked accidental.

It sits flush with the top rather than inset there: with a margin above it, scrolled photos showed as a sliver over the bar, which reads as a glitch instead of as depth.

One thing that took a moment to find: because the bars are bound to the viewport, and the viewport shrinks whenever the scrollbar or the timeline rail appears, the header kept a stale width — the page's own resize event never hears about that. They are repositioned from an event filter on the viewport itself.

VRChronicle 1.8.0

The grid scrolls under the header, and the header is glass

The header buttons could not show photos behind them, because the header sat in a band above the grid — there was nothing behind it. Frosting it there would have been a picture of glass rather than glass.

So the grid now fills the page and the header floats over it. The photos really do pass underneath, and the bar samples them, blurs them and tints them.

The controls went translucent to match — a solid search box or pill on a frosted bar punches an opaque hole in it. The bar stops where the timeline rail begins, so it does not sit on its year labels.

Underneath, the grid model grew a spacer row as tall as the header. That is what keeps the first day from starting life hidden: the obvious alternative, viewport margins, stops the content scrolling under the bar at all — which is the entire point.

A debugging note worth keeping

Adding that spacer crashed the process natively, with a stack that pointed only at a test line. It was not the glass and not the item flags: the month-mark scan walked every row and read a date off the spacer's integer payload, and that AttributeError was raised inside a Qt slot — which takes the whole process down rather than printing.

When a Qt app dies with an access violation, look for a Python exception on a slot first.

Tests 108 → 109, including one that asserts photos really are behind the bar and that the first day is not hidden by it.