rereading "photo" to redisplay it in a canvas

[ggw]

My wrapped application is working... but I run out of memory.

That is because I keep creating a new image about every 2 seconds.

I have yet to understand the relationship between these 4 actions:
1) pack [.....] [canvas .d -width 1024 -height 1024] ......
2) set dispix [ image create photo -file "dispixmap.ppm"]
3) .d create image 0 0 -anchor nw -image $dispix
4) somehow re-read dispixmap.ppm into $dispix; and somehow command
the canvas widget to re-transfer the contents of $dispix onto the
canvas.

The filename never changes, but its contents change all the time. I
only need the one "image object".

In tests I have done it takes less than 1/2 second to do it the long
way by repeating steps 2 and 3.

What is the sensible code that would make up step #4?
ggw

[drsc...@gmail.com]

On 12/4/2010 5:48 PM, ggw wrote:

> What is the sensible code that would make up step #4?
> ggw

Delete the image that you no longer need? Just do it before refreshing
it with the new version.

DrS

[Aric Bills]

$dispix blank; $dispix read "dispixmap.ppm" -shrink

[ggw]

#4
The read turns out to be:
$dispix read "/sms/image/dispixmap.ppm"

Thanks for the info on that!

#4
The update of the canvas turned out to be..... NOTHING!
I removed all the canvas references except #1 and #3 and the program
is running faster than ever. It is usable now.

I must have crashed my application 20 times getting this.

But... its over... for now.

I suspect I'll be back with more wonderments probably having to do
with influencing which colors are shown.

Thanks to you 2 for your help this time.

By the way. Any idea why on this solaris10 box that the colors are
interpreted RBG instead of RGB? Is it a Tk bug to not have sussed out
the properties of what ever visual Tk ended up using? I changed my
underlying code to follow a variable I introduced last weekend, "rgb"
to default to 123, but I have to set it to 132 in order to get the
colors to be proper. Who would I consult about that? Should I dive
into the Tk color handling (god forbid)?

Gimp shows that my dispixmap.ppm default picture does have the correct
coloration.

ggw

[Uwe Klein]

ggw wrote:
> My wrapped application is working... but I run out of memory.
>
> That is because I keep creating a new image about every 2 seconds.
>
> I have yet to understand the relationship between these 4 actions:

well:

> 1) pack [.....] [canvas .d -width 1024 -height 1024] ......

# this can be separated into
# create a canvas widget:
set canv [ canvas .d -width 1024 -height 1024 ]

# pack this widget into the ( already existing ) toplevel window "."
# which makes the created widget visible
pack $canv

> 2) set dispix [ image create photo -file "dispixmap.ppm"]

# create an image "object"

set dispix [ image create photo -file "dispixmap.ppm"]

> 3) .d create image 0 0 -anchor nw -image $dispix

# create an element of the type "image" on the canvas using
set element_id [ .d create image 0 0 -anchor nw -image $dispix ]
# you would gain some more insight if you read up on
# the image command manpage. ( same for the canvas manpage ;-)

> 4) somehow re-read dispixmap.ppm into $dispix; and somehow command
> the canvas widget to re-transfer the contents of $dispix onto the
> canvas.
>
> The filename never changes, but its contents change all the time. I
> only need the one "image object".

If you want to get crafty you could create multiple image objects
and reload them with new image information round robin style
and then just raise the newly loaded imageobject on the canvas.

$canv raise $lement_id

OK:
proc update_raise_image {canv imagetag newfile} {
set image [ $canv itemcget $imagetag -image ]
$image read $newfile
$canv raise $imagetag
}

uwe

[Donal K. Fellows]

On Dec 5, 2:50 am, ggw <gwy...@io.com> wrote:
> By the way. Any idea why on this solaris10 box that the colors are
> interpreted RBG instead of RGB? Is it a Tk bug to not have sussed out
> the properties of what ever visual Tk ended up using?

That's very strange. Tk's supposed to be able to handle such byte
reorderings for you (the guts of X11 image handling are really very
nasty indeed) and we'd love to know what's going on in more depth
there. Alas, it's so long since I last did work in this area (and I've
not got a Solaris box with a display) that I can't tell you what
information it would be helpful to have first; I just can't remember
what command to run to look it up (Tk itself doesn't say, so we're
talking some program installed with X11 itself).

Donal.

[ggw]

My error (of course). I jumped to conclusions. I needed to read
carefully about the ppm header, not just assume what something is for
AND feel justfied because my first test example on one workstation
worked. Those assumptions will "get cha". Delayed me through 6 hours
of further debugging and useless workaround code.