Also stored in the database file is a thumbnail image of each image media item attached. It is the thumbnail you see on screen, not the original, unless you edit the item or generate a report. I suspect that lots of thumbnails will have a marked effect on database file size and slow operations due to disk performance but it will take a very great many to do so. What you will see much earlier is a slowing of the Media Gallery when showing thumbnails - it can become virtually unusable.
That was about RootsMagic 5. Two versions later and it has not improved (maybe it has -see update below). This blew up on me when I just expanded my master database with an import from FTM of a sync'd Ancestry tree bring with it over 600 source images, expanding my gallery to 800 items. Previously with fewer than 200 items (and many of those being PDFs having no thumbnail), I was not bothered by balkiness when scrolling through the gallery. Now, I have uncontrollable pauses and jumps as the screen is rendered for a batch of files. The interruptions vary from 2-18 seconds in a small sample of scrolls, freezing the screen on the last batch viewed with no ability to continue to scroll through the unrendered thumbnails and read the file name or caption.
Contrast that to the way Windows File Explorer functions when viewing icons. It renders the thumbnails for those files in view (not all those between where the scroll started and ended) and you can scroll smoothly through without waiting for any to complete, reading the filename as you go.
RootsMagic appears to be working very hard when you scroll to or past some threshold with frequent updates to the database file as indicated by the number of SQLite journal files created and deleted during the interruption. This should not have anything to do with creating the thumbnail binary stored in the database as that much slower process was already completed (so I thought - but maybe not). To display the thumbnails requires fetching the small binary blobs from the database and rendering them to the screen. I don't know why the database itself would need any updates (a journal is not created for a read-only operation).
RootsMagic Inc extols the virtues of the SQLite database as being virtually unlimited when people ask about how many people it can hold. This is an example where the application design fails to support a relatively small number of items in one of its features (maybe overstated but with the addition of a large number of media items, e.g., using drag'n'drop, the Media Gallery can consume a lot of resource processing image files into thumbnails).
----------------------------
Update: as I wrote this and kept going over Media Gallery operations, performance improved. The range I could scroll without interruption increased and the length of the interruption decreased to the point that there seems to be but one interruption of a second duration, a journal file momentarily appears, and a skip in the display when scrolling from top to bottom and vice versa. Highly repeatable around the same locations.
