The OP provided the correct fix in his self-answer but missed to explain why this is necessary. So, I will step in:
Qt doc. about QImage::QImage()
:
Constructs an image with the given width, height and format.
A null image will be returned if memory cannot be allocated.
Warning: This will create a QImage with uninitialized data. Call fill() to fill the image with an appropriate pixel value before drawing onto it with QPainter.
(Emphasize mine.)
Uninitialized means there might be any value in the image pixel bytes. If it were all 0
s, the alpha values would be 0
s as well. That might explain why there appeared nothing.
Now, an additional note why this may have worked in debug mode:
OP mentioned explictly MSVC. The MS guys tried to provide best support for debugging and decided to fill every allocated memory (in debug mode) with patterns like e.g. CD
standing for "allocated but not yet initialized". (More about this here: SO: In Visual Studio C++, what are the memory allocation representations?.)
Sometimes, it is really helpful. Interpreting this bit-pattern as float
or double
yields quite strange numbers (easy to recognize with a little bit experience), and integral values in hex-view become quite obvious.
However, this has some draw-backs: An uninitialized bool
will be always "initialized" to true
in debug mode (somehow) where it has arbitrary values in release. → The worst imaginable accident: debug runs but release fails sporadically. (My most afraided bugs.)
In OP's case, it's (probably) similar: In debug mode, the image has always a light gray background with an opacity which is high enough to ignore the unexpected transparency while in release mode... see above. (Alternatively, the OP could've get a noise pattern as well like known from TV after midnight in the past. Not sure, whether this had helped further...)