[jitter] "prepend texture" vs "jit.gl.texture"

> -question 1-
> I've noticed that a texture created with the "prepend texture" message has a lower quality than one created by a jit.gl.texture (with the same image). I have to read the same image at the double of resolution (and more) to have the same quality.

>
> -question 2-
> With the "prepend texture" message I can delete the texture from the video memory with "deletetexture" message, how can I delete the jit.gl.texture memory? Only deleting "physically" the object?
>


Do you have an example patch?  I'm not really sure what you're
describing here.  Are these messages to jit.gl.render?  I would
recommend using jit.gl.texture for anything texture related.  Also,
why do you need to worry about deleting the texture's memory?  Is
there some kind of memory related issue you're coming across?


> -question 3-
> How can I reproduce the "lighten" and "screen" layer's filters normally used in photo-editing software? I use many GL layers with blend_enable activated.
>

You may want to render your scene to a texture and use jit.gl.slab to
do some kind of scene post processing.


> -question 4-
> In a scene I have 48 "jit.gl.gridshape @shape plane dim 2 2" with texture (butterflies) moving around the screens with many many "drunk", "scale", "rotate", "line", etc. The movements slow down (low fps) but the cpu's graphic in the Task Manager show the cpu "relaxing".
> Less GL-objects -> more fps and the cpu work more...
> Why the cpu don't work well? It's a graphic card problem? I use two Radeon X1300 and a Core Duo 2 cpu.
> Should be better with a javascript's programming?
>

use jit.gl.gridshape @displaylist 1.  That should speed things up
quite a bit.  Also, if you can express the patterns controlling the
gridshapes in a matrix, you may want to look at using jit.gl.multiple
for controlling the 48 gridshapes.


> -bug 1-
> When I have the 3 windows in fullscreen mode in the 3 monitors and I resize the patch's windows, the borders make "garbage lines" and the windows don't resize really. I have to use the "window size xxx yyy, window exec" message or disable the fullscreen of the 3 screens.


Again, do you have a simple example patch that reproduces this bug?
If its an interface bug, it's something that has probably been
addressed in Max5.

wes