Evans,
Add , SIZEPOLICY=FIXED to your image definition.
Looking at the log, I can see that the image name is sent in a third shot:
Fri 22. Oct 16:55:53 2010:5 : om 0 { {an 0 UserInterface 0 { {
...
Fri 22. Oct 16:55:55 2010:5 : om 1
..
Fri 22. Oct 16:55:55 2010:5 : om 2 { ... {un 95 { {numAlign "0"} {value "logo.png"}}} { ...
So the image arrives after the first window has already been displayed.
As SIZEPOLICY is not defined for your image, it is "initial" by default, which means the image size will be fixed regarding the content on first display, which is an empty image.
Then when the picture arrives, the image size is already fixed, and is not updated (because sizepolicy = initial).
Note that the issue occurs because initially the image field has no value, we've an internal mechanism to postpone fixing the size if we know there is an image that is supposed to come (because there is a value) after the first display, even if sizepolicy=initial.
What changed with 2.20:
1. the communication is in its own thread, so the GUI can be built immediately after the first part. In 2.11 it may happen that the GUI had to wait until the complete runtime group of messages. Which means that the "first display" was done lately, when the image file was already set as a value.
2. because of several bugs related to images, we had to review how image attributes are working together. The review ended up with the width / height attribute could only be supported with SIZEPOLICY=FIXED:
width and height mean that the image should have a given size, but sizepolicy=dynamic/initial means that the image should have the size of the picture. So who wins ? sizepolicy or width/height ?
So now with 2.2+ width / height attributes are only taken into account if SIZEPOLICY is set to FIXED, i.e. that it is explicitly defined that the size is not driven by the content.