Specific PNGs lead to crashes.

[justnullname]

@justnullname, gallery filmstrip thumbnails are fixed, thank you, and there's some progress with indication popup for loop and zoom, however, for some reason both indications' backgrund color is slightly different from all other widgets: it's #F2F2F2 for zoom/loop and #F2F2F7 for all other (marked with green arrows). This leads be to believe indication poput is still imperfect. Please double-check what's going on with it.

I have also noticed the hover for filmstrip gallery view appears in settings window, I absolutely shouldn't.

And Settings → Interface → Custom Lite Info Panel in English has wrong case for 'Items in Normal mode' and 'Items in Compare mode'.

Lastly, this PNG is still crashing QuickView for me even with prefetched set to off and RAM management set to smart.

Originally posted by @bananakid in #144

[justnullname]

Hi, @bananakid, could you please tell me the exact steps you took when the crash happened while viewing this PNG? For example, did you drag it from an archive, a file manager, a third-party application, or somewhere else? I am unable to reproduce this bug locally, so I suspect it might be caused by temporary files being deleted. Could you please provide detailed steps to reproduce the issue?

[bananakid]

@justnullname, I'm using RAM virtual disk for %Temp% and I open image using QuickView's welcome screen or by dragging & dropping PNG onto QuickView window, it crashes in both scenarios. When I moved %Temp% off RAM virtual disk, the PNG file opened successfully. However a new file was created in %Temp% — QuickView_TitanPool_4972_C90E9E3F.bgra with the size of 5.00 GB (5,368,709,120 bytes)! Is that supposed to happen for this specfic PNG? No *.BGRA files are crated by QuickView in %Temp% when I view other large PNG images like 7680×4320. Last time I checked QuickView never wrote anything to disk for viewing files (and working strictly from RAM was one of the main features for considering it as a primary viewer). In example, qView opens the same file without writing to disk. Please look into it, might be a bug. Thank you for inspecting this.

[justnullname]

Hi @bananakid,

Thank you so much for the detailed follow-up and the critical clue about the RAM virtual disk! This perfectly explains the crashes you were experiencing.

Here is exactly what is happening under the hood, why that 5.00 GB file appeared, and why it broke your setup:

1. Why we designed the 5GB file (The TitanPool mechanism):
   When handling extremely large images, QuickView switches to a special "Titan" mode to prevent the app from exhausting physical memory and causing Out-Of-Memory (OOM) crashes. To safely manage memory, we pre-allocate a 5GB Memory-Mapped File (MMF) pool in the %Temp% directory as a safety buffer.

2. Why it usually writes nothing to the disk (The Sparse File trick):
   On standard NTFS drives (like a normal SSD or HDD), this 5GB file is marked as a "Sparse File." This means that although it appears to be 5GB, its actual physical footprint on the disk is 0 bytes. The OS only allocates physical sectors dynamically as needed. This allows QuickView to maintain its "zero-disk-write" and pure RAM philosophy while having a massive safety net for giant images.

3. Why it crashed on your RAM Disk (The compatibility conflict):
   The problem arises because most third-party RAM Disk drivers do not perfectly support the NTFS sparse file attribute. When QuickView attempts to create this 5GB sparse file, the RAM Disk driver ignores the "sparse" flag and tries to forcefully allocate the full 5GB of actual RAM instantly. This instantly exhausts your RAM disk capacity, causing a page-in failure (STATUS_IN_PAGE_ERROR), which directly leads to the severe crash.

You make a fair point. Reserving 5GB for normal images is definitely excessive. That value was initially a workaround specifically for gigapixel satellite imagery.

Next Steps:
I am currently working on a deep architectural fix for this issue. We are redesigning the buffer into an elastic, dynamically allocated pool with a proper fallback mechanism. This will completely eliminate the brute-force 5GB sparse allocation and ensure compatibility with RAM Disks.

Once the fixed version is ready for testing, I will update this thread to notify you. Thanks again for your invaluable help in tracking down this issue!

[justnullname]

Hi, this issue has been fixed. Please switch to the pre-release channel to update and test it.

[bananakid]

@justnullname, thank you for addressing this and also providing a throughout explanation. Unfortunately it's not perfect yet. For reference, my computer's specs: 256 MB RAM disk (~200 MB free), 16 GB RAM, Intel Core i9-9880 CPU, AMD Radeon Pro 5600M 8 GB GPU, 3072×1920 HiDPI display, Windows 10 version 21H2 build 19044.1288 (200% scaling).

When I'm testing with the same reference PNG provided earlier and my custom zoom levels are FixedZoomLevels=0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75,0.8,0.85,0.9,0.95,1,1.25,1.5,1.75,2,4,8,10, at smaller scale (25% and below) some chunks of the image go missing:

Also if I open this PNG and start zooming immediately, it won't actually load image and thumbnail won't zoom past some point and will keep loading like this, then if you wait computer starts overheating and zooming becomes slow:

Capture.mp4

I assume the performance should be adjusted further as qView opens and zooms the same PNG perfectly (though it takes 2-3 seconds to initially display it).