vade

Mixing textures of different dims through a jit.gl.imageunit (with an 

image unit loaded that uses two inputs) results in the smaller dimed 

texture *not* being scaled to the output dim of the 1st texture. This 

results in a 'picture in picture' effect. This happens regardless of 

Hardware/Software - Mac OS X 10.4.6 - Powerbook G4 1.6.7 128Mb VRam 

Max 4.6 public beta Jitter 1.6 public beta

Expected behavior: Well, Im uncertain how this should work. IMO 

ideally the texture dims would be matched to the leftmode inlets 

texture dims. But is this something we will have to manage ourselves? 

the MOP object does this for matrices in jitter land, so id expect 

Also, I have been able to reproduce a memory leak by changing the 

size of the window when working with jit.gl.imageunit - it seemed to 

happen more with @colormode uyvy, but I could get it to do it in argb 

mode. I havent figured out what exactly causes it, but watching top 

with the patch open I notice a memory increase.

Mixing textures of different dims through a jit.gl.imageunit (with an  
image unit loaded that uses two inputs) results in the smaller dimed  
texture *not* being scaled to the output dim of the 1st texture. This  
results in a 'picture in picture' effect. This happens regardless of  
colormode.

Hardware/Software - Mac OS X 10.4.6 - Powerbook G4 1.6.7 128Mb VRam  
Max 4.6 public beta Jitter 1.6 public beta

Expected behavior: Well, Im uncertain how this should work. IMO  
ideally the texture dims would be matched to the leftmode inlets  
texture dims. But is this something we will have to manage ourselves?  
the MOP object does this for matrices in jitter land, so id expect  
something equivalent.

Also, I have been able to reproduce a memory leak by changing the  
size of the window when working with jit.gl.imageunit - it seemed to  
happen more with @colormode uyvy, but I could get it to do it in argb  
mode. I havent figured out what exactly causes it, but watching top  
with the patch open I notice a memory increase.

jitter-1-6-a-few-issues-with-imageunits-dims-memory-leak

> Mixing textures of different dims through a jit.gl.imageunit (with 

> an image unit loaded that uses two inputs) results in the smaller 

> dimed texture *not* being scaled to the output dim of the 1st 

> texture. This results in a 'picture in picture' effect. This 

Sorry, but this behavior won't change and is the way imageunits work 

with different sized inputs. And for some kinds of additional image 

inputs (like gradient image inputs), you explicitly don't want to 

upsample to the lefthand texture size. So yse, this is something 

you'll need to manage yourselves, but you can do so without much 

Just use an instance of jit.gl.slab @adapt 0 @dim , 

before the righthand input to jit.gl.imageunit. You can also avoid 

the green border problems visible with UYVY textures and certain 

image units which extend black (uyvy green) for regions outside the 

image, but using jit.gl.slab before jit.gl.imageunit to always 

convert the uyvy data to argb data before the imageunit. Again this 

is something you'll need to manage yourself. This incurs a slight 

performance penalty, so we won't force it to happen for all cases. We 

might figure out a solution to this in the future, but this is the 

On Jun 24, 2006, at 8:44 PM, vade wrote:
>
> Mixing textures of different dims through a jit.gl.imageunit (with  
> an image unit loaded that uses two inputs) results in the smaller  
> dimed texture *not* being scaled to the output dim of the 1st  
> texture. This results in a 'picture in picture' effect. This  
> happens regardless of colormode.

Sorry, but this behavior won't change and is the way imageunits work  
with different sized inputs. And for some kinds of additional image  
inputs (like gradient image inputs), you explicitly don't want to  
upsample to the lefthand texture size. So yse, this is something  
you'll need to manage yourselves, but you can do so without much  
dificulty.

Just use an instance of jit.gl.slab @adapt 0 @dim  ,  
before the righthand input to jit.gl.imageunit. You can also avoid  
the green border problems visible with UYVY textures and certain  
image units which extend black (uyvy green) for regions outside the  
image, but using jit.gl.slab before jit.gl.imageunit to always  
convert the uyvy data to argb data before the imageunit. Again this  
is something you'll need to manage yourself. This incurs a slight  
performance penalty, so we won't force it to happen for all cases. We  
might figure out a solution to this in the future, but this is the  
behavior Jitter 1.6 will ship with.

Jitter 1.6 a few Issues with imageunits - dims - memory leak? ?