postrender is executed a bit early, when associated with triggers

[ch-nry]

postrender is executed a bit early, when associated with triggers

[ch-nry]

It turn out this feature is documented, in pix_texture help file.
I create a pull request to have it more visible :
#430

[umlaeute]

hmm.

[render_trigger] really behaves the same as [trigger] (with the outlets swapped).

it was necessary at a time (more than 2 decades ago), when [gemhead] would not emit a message for each render tick.
it shouldn't be used these days.

i couldn't even tell which part of the your example patch behaves unexpectedly.

[ch-nry]

This follow a discussion in the pd list where I noticed that pix_texture is detached from the gemchain before the end of the gemchain if triggers are involved.
I use [render_trigger] to show that the the problem is the post render code that is executed earlier that what I expected.

[ch-nry]

trigger_in_gemchain.pd.zip
Here is a patch that show the unexpected behaviours.

[umlaeute]

from a conceptual model, i think the current behaviour is the only sane option. (we do need to cleanup the render-state at some point, and once a subtree has done it's work seems to be a good time). (e.g. 1d273ca)

regarding the textures: i think this patch is correct in not applying a texture:

|
[pix_test]
|
[t a a]
|     [pix_texture]
|
[square]
|

otherwise, it would be very hard to build a subtree without the texture.

i think the proper way to get the texture to the other branch, is by explicitly passing it:

|
[pix_test]
|
[t a a]
|     [pix_texture]
|                 |
[pix_texture      ]
|
[square]
|

(currently it also works without connecting the 2nd iolets of the two [pix_texture] objects, but i think this is purely accidental and should not be relied on.)

the first example (using [gemlist]) could probably be considered a bug.
however, getting it right would involve duplicating a lot of functionality from [pix_texture] into [gemlist], and i'm not sure whether this is a good idea (as compared to just using another [pix_texture] as shown above)

[ch-nry]

Since I was not expected this behaviours, I use a lot of pix_set to "reset" the texture to white.
anyway, pix_texture is not the only object that use postrender. [alpha] is also disabled in postrender.
(I did not have a deep look at all the objects that use postrender)
This behaviours is alarming for me since there are lot's of patch and documentation, including in Gem example, where it is explain (or at least, based on) that outA and outB are equivalent :

[gemhead]
|
[t a a]
|     [cube]
|       |
|      [outA]
|
[outB]

My real user case was :

[gemhead]
|
[t a a]
|     [spigot]
|       |
|      [pix_image]
|       |
|      [pix_texture]
|
[cube]

I was expecting the texture to be activated or deactivated with the spigot.

The solution is obvious :

[gemhead]
|
[t a a]
|        \
|          \
|            \
[spigot]      |
|            [spigot]
|             |
|            [pix_image]
|             |
|            [pix_texture]
|           /
|         /
|      /
|   /
[cube]

But it look less elegant.

For me, the good moment to cleanup the render-state is at the end of the gemhead tree.

But, well, I'll probably have to adapt if you think the current behaviours is the best one.

[ch-nry]

post_render_and_gemchain_clean.pd.zip

This example show that cleaning the transformation matrix is only done after the gemhead tree.
it can't be reset at the end of the sub-tree for obvious reason. (it could have been cleaned at the beginning of the gemhead, but that would break lot's of useful feature)
I always assume it was cleaned at the same time as the post_render.
Except for compatibility with old patch, I still have hard time understanding why the post render should not be trigged latter.

[ch-nry]

This behaviours is alarming for me since there are lot's of patch and documentation, including in Gem example, where it is explain (or at least, based on) that outA and outB are equivalent :

See Gem example/02.advanced/19.pointer.pd

[60-hz]

There is an undocumented feature of pix_texture to desactivate the texture mapping by simply sending 0/1 to its first inlet. It also should works with other pixel effects. This might be added to help file I guess.