[GEM-dev] [ pd-gem-Bugs-2972166 ] pix_crop, pix_resize don't "refresh" when they should

[SourceForge.net]

Bugs item #2972166, was opened at 2010-03-17 21:12
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_crop, pix_resize don't "refresh" when they should

Initial Comment:
If you use a pix_crop on a pix_film:
[pix_film]
|
[pix_crop]

when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode)

I don't know whether this is an issue with pix_film or pix_crop.
This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film.

Then [pix_resize] has a similar issue:
if you have:

[pix_film]
|
[pix_resize]

OR

[pix_image]
|
[pix_resize]

when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!!

This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image].

I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture].

I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file.

And now a nastier thing, possibly related:

1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s
    You see the four images, twice the image and twice the video
2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output
3) move the [pix_film] on the right to the render chain on the left and connect it

You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!!

This is probably the same bug described above.
Try all the viceversa's

----------------------------------------------------------------------

>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-05-07 10:51

Message:
you can use [pix_separator] to workarund.

fgmasdr
IOhannes

----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2010-03-17 23:18

Message:
With pix_film, if you have to change a crop or resize of the image while
not changing the frame, even sending the same frame number again won't
work: the cropped or resized image won't be refreshed until pix_film
actually goes to a different frame. So it is not "workaroundable"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_id=64325