PtRaw and its draw function: timing?

Momentics with IDE 4.0 in Windows loading into target machine which
displays into nice touch screen monitor.

Situation A: I fetch an image from a file and load it into a PhImage_t
structure using PhCreateImage(). PtDamageWidget() invokes a draw
function specified in the Pt_ARG_RAW_DRAW_F resource of a PtRaw
widget. The draw function uses PgDrawPhImage() and, presto, I get a
good looking result in my PtRaw. I then release the structures
allocated and am ready for another image file selection. No nasty
growth of malloc’d space.

Situation B: Same as A except after displaying the image from a
selected file a message is sent to another process which returns some
lines to be overlaid on the image. The lines are transformed into
screen coordinates, stuffed into a data structure that can be found
by the draw function (structure also contains pointer to PhImage).
Another PtDamageWidget call results in a nice image too and with
lines as expected.

The problem: in “B” I can’t figure out where/when to free()
the allocated space. The draw function gets invoked typically three
times although I call the damage function only once. I don’t care
how many times the draw fn. gets called as long as I can free the
prior image and lines. As things are now, I can watch the malloc’d
space grow in the System Info view. Any placement of
“free” operations results in a crash of Photon and my HMI
screen goes away. Somebody stop it.

Actually, you never can be sure that your widget won’t have to be redrawn
(entirely or partially) during all its life on the screen. So you should
keep
all the data necessary for redrawing until you widget changes
its appearance or is destroyed. And at least your draw function
should check whether the pointers which it uses are still valid.

“rlb” <robert.bottemiller@fmcti-dot-com.no-spam.invalid> ???/??? ?
??? ???: news:er5gim$se$1@inn.qnx.com

Momentics with IDE 4.0 in Windows loading into target machine which
displays into nice touch screen monitor.

Situation A: I fetch an image from a file and load it into a PhImage_t
structure using PhCreateImage(). PtDamageWidget() invokes a draw
function specified in the Pt_ARG_RAW_DRAW_F resource of a PtRaw
widget. The draw function uses PgDrawPhImage() and, presto, I get a
good looking result in my PtRaw. I then release the structures
allocated and am ready for another image file selection. No nasty
growth of malloc’d space.

Situation B: Same as A except after displaying the image from a
selected file a message is sent to another process which returns some
lines to be overlaid on the image. The lines are transformed into
screen coordinates, stuffed into a data structure that can be found
by the draw function (structure also contains pointer to PhImage).
Another PtDamageWidget call results in a nice image too and with
lines as expected.

The problem: in “B” I can’t figure out where/when to free()
the allocated space. The draw function gets invoked typically three
times although I call the damage function only once. I don’t care
how many times the draw fn. gets called as long as I can free the
prior image and lines. As things are now, I can watch the malloc’d
space grow in the System Info view. Any placement of
“free” operations results in a crash of Photon and my HMI
screen goes away. Somebody stop it.

Situation “B” is now handling freeing malloc’d space well.
I paid a bit more attention about placement and timing of memory
release and testing of pointers.

There is still one oddity: the display list is pointed to by A and
contains the pointer B. B has been allocated space to C1, …, C4
which are 4 pointers to further data. This sequence:
free(A->B->C1), …,
free(A->B->C4)
works cleanly but the intended last step:
free(A->B)
results in the HMI application crashing. It appears to me that B is
still non-NULL and application of “free(A->B)” would be
valid. Further experiments will take place after higher-priority
issues.

Thanks, a_o, for the advice!

rlbwrote:

There is still one oddity: the display list is pointed to by A and
contains the pointer B. B has been allocated space to C1, …, C4

which are 4 pointers to further data. This sequence:

free(A->B->C1), …,
free(A->B->C4)
works cleanly but the intended last step:
free(A->B)
results in the HMI application crashing. It appears to me that B is
still non-NULL and application of “free(A->B)” would be

valid. Further experiments will take place after higher-priority
issues.
If I right undestand, then you can’t free(A->B) because you didn’t
allocate it (i think you declared struct A with field pointer B to
some *void), so you cann’t free it.