Florent Ghys

I have been noticing this strange behavior in a few of my patches for a while and I am wondering if I am doing something wrong or if it's a bug. 

There is a single jit.gl.videoplane @position 0. 0. 0. and a jit.world @position 0. 0. -2. 

When I load the patch, jit.window is loaded on my Mac's monitor and it placed at the center, but when I drag the window to another monitor or a video projector, the videoplane is then moved to a corner. 

Then, changing the z position of jit.world does not anchor at the center.

flonum

prepend

jit.gl.videoplane

jit.world

toggle

I have noticed that sending [visible 0] and back [visible 1] to jit.world puts back the videoplane at the center, but then Max crashes when I play a hap video. 

This behavior is problematic as it seems to be unpredictable and it happened during performances in which I had to manual readjust the videoplane's position to this weird angle.

I am using Max 8.0.3 and macOS 10.14.3 and have experienced this issue with multiple monitors and video projectors. 

Hello,
I have been noticing this strange behavior in a few of my patches for a while and I am wondering if I am doing something wrong or if it's a bug. 

There is a single jit.gl.videoplane @position 0. 0. 0. and a jit.world @position 0. 0. -2. 
When I load the patch, jit.window is loaded on my Mac's monitor and it placed at the center, but when I drag the window to another monitor or a video projector, the videoplane is then moved to a corner. 
Then, changing the z position of jit.world does not anchor at the center. 

I have noticed that sending [visible 0] and back [visible 1] to jit.world puts back the videoplane at the center, but then Max crashes when I play a hap video. 
This behavior is problematic as it seems to be unpredictable and it happened during performances in which I had to manual readjust the videoplane's position to this weird angle. 

Any idea of why this is happening? 
I am using Max 8.0.3 and macOS 10.14.3 and have experienced this issue with multiple monitors and video projectors. 

Florent



Hello,
I have been noticing this strange behavior in a few of my patches for a while and I am wondering if I am doing something wrong or if 

moving-jit-window-to-another-monitor-changes-the-gl-camera-angle

I think I have the same problem, reported here, but no replies so far:

https://cycling74.com/forums/what-does-highres-1-actually-do

The problem seems to be related to @high_res 1.

https://cycling74.com/forums/what-does-highres-1-actually-do 

thanks Martin, I remember reading your post, there is also another person out there with apparently the same kind of problem

do you notice a difference in terms of quality when you turn off high res? 

thanks Martin, I remember reading your post, there is also another person out there with apparently the same kind of problem
do you notice a difference in terms of quality when you turn off high res? 
I'll send a bug report
Florent

@high_res 1 is quiet essential for me. Texture quality is much better and also speed performance is much better - @high_res 0 with mipmap filtering does not yield the quality of @high_res 1.

I "solve" the described problem with changing the viewport settings, but the problems with jit.gl.handles remain.

@high_res 1 is quiet essential for me. Texture quality is much better and also speed performance is much better - @high_res 0 with mipmap filtering does not yield the quality of @high_res 1.
I "solve" the described problem with changing the viewport settings, but the problems with jit.gl.handles remain.

thanks for sharing this, I'll try @high_res 0 in my patches. I'm mostly playing video files in videoplanes so it might not make a big difference for me

The workaround I'm using for this is to add the high_res attribute to the jit.world object and manually switch high_res 0 every time I move the window from main monitor (retina) to extended, and then manually re-enable high_res 1. After turning it ON again, everything is centred again (at least for me).

apologies for missing this the first time around. I've tried to address this issue of dragging a high_res enabled window from a retina-enabled display to a non-retina-enabled display in the past, but the fix had some very undesirable side effects.

for now, the work around is to simply rebuild your context (toggling high_res will do the trick). I will ticket this issue for future investigations.

thanks Rob and Rarasmus, toggling high_res works!

Moving jit.window to another monitor changes the gl.camera angle?