Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

[macOS/Metal] Memory usage reaches 12.8 GB while working with a 896×1344 RGB image (PixelOver 0.19.1)

A topic by JoromeAX created 47 days ago Views: 240 Replies: 5
Viewing posts 1 to 3

Hello,

I may have encountered a graphics-memory retention/leak issue in PixelOver 0.19.1 on macOS. I searched the existing Report topics but could not find the same issue.

Environment

- PixelOver 0.19.1 stable, Steam version

- macOS 26.5.2 (build 25F84)

- MacBook Pro (MacBookPro18,2)

- Apple M1 Max, 32-core integrated GPU

- 32 GB unified memory

- Metal renderer

Image used

- PNG, 896 × 1344 pixels

- 8-bit RGB, non-interlaced

- File size: 84 KB

Observed sequence

1. I launched PixelOver 0.19.1 and worked with the attached 896 × 1344 image in a 2D project.

2. After approximately nine minutes, Activity Monitor reported 12.4 GB of memory for PixelOver.

3. A `vmmap -summary` capture shortly afterwards reported a 12.8 GB physical footprint.

4. The application remained responsive and macOS compressed most of the allocation, but the memory remained attributed to the PixelOver process.

Observed memory details

- PixelOver physical footprint: 12.8 GB

- Writable regions: 13.1 GB total

- Compressed/swapped writable memory reported by vmmap: approximately 12.0 GB

- `owned unmapped (graphics)`: 11.5 GB

- Approximately 2,674 `owned unmapped (graphics)` regions

- Activity Monitor showed 12.06 GB compressed memory and 0 KB disk swap

The process RSS later appeared much smaller (approximately 650 MB), but `vmmap` still reported the 12.8 GB physical footprint because most of the graphics allocation had been compressed.

Log observation

The session log contains 7,447 repetitions of this error:

ERROR: Condition "p_dest->get_format() != p_src->get_format()" is true.

   at: merge (custom_modules/pixelover_module/po_image/po_image.cpp:511)

This repeated image-format error appeared during the same session as the graphics-memory growth.
The full session log is available on Google Drive:
https://drive.google.com/file/d/1_BsIL6ATFB2Aqw_XXEQBvel3NSsScrrg/view?usp=sharing

Expected result

PixelOver should reuse or release intermediate graphics buffers, and a single 896 × 1344 RGB image should not cause the process footprint to grow to approximately 12.8 GB.

Actual result

Graphics allocations accumulated to approximately 11.5 GB and remained retained/compressed while the PixelOver process stayed open.

Reproduction note

I have captured this occurrence with the full log and memory diagnostics, but I have not yet isolated the exact editor operation that begins the accumulation. Please let me know if you would like me to test a specific action, renderer setting, image format (RGB versus RGBA), or canvas size.



(1 edit)

Hello, thank you for this detailed report, I guess it's linked with the drawing tool, this will be fixed for the next patch

I couldn't reproduce the memory leak, but I've implemented two fixes:
- Fixed an issue when drawing onto compressed images, which was causing the error: ERROR: Condition "p_dest->get_format() != p_src->get_format()" is true.
- Optimized resource usage during drawing.

Patch released.

Hi Deakcor,

Thank you for responding and releasing the patch so quickly. I updated the Steam version to PixelOver 0.19.1.1 and continued working with the same project and 896×1344 RGB image.

The image-format error from my original report does not appear in the new session log. Thank you for fixing that.

The memory attributed to PixelOver still rises when I draw or erase. It was about 353 MB just after launch, before opening the project; after approximately 38 minutes of work, Activity Monitor showed 9.09 GB. The Mac remained responsive, memory pressure was green, and disk swap was zero. A later vmmap capture from the same running process reported a 10.5 GB footprint, including 4.5 GB of owned unmapped (graphics) regions.

I also noticed repeated Condition "idx < 0" is true errors in the new log, often near undo activity. I don’t know whether they are related to the rising memory figure.

Both screenshots, the full new session log, and the vmmap output are in this folder: https://drive.google.com/drive/folders/1CqY2Ggl2U71wo_UFst4EGhtgVOMdy9lY

Could you take another look at what is being retained during drawing and erasing?

Ah yes I guess it's because the images are kept in the memory for the versioning (undo/redo). So they need to be stored in the disk for the session instead. Ok the fix will be less quick, but it will be done for the next update, thank you again for the detailed report.

Hi, it should be well fixed now.