aalex

I am experiencing some quite annoying tearing on a video projector. I triggered the "sync" attribute of jit.gl.render with no succes. I think it might be an issue with the ATI Windows driver, though. If so, it might be hard to fix. Below is the list of hardware and software options we use. If anyone has an hint, it is more than welcome !!

* PC with Intel Core 2 Duo (ASUS) on Windows XP SP2

* ATI video card : ASUS EAH2900XT/G/HTVDI/512M

* Projector : seems to do it on any one we tried. We are using the Christie DX+25 (as a second monitor)

* I am using a lot jit.gl.lua, but it doesnt seem to make a difference

* video driver : Catalyst Control Center (advanced)

* the projector is not set as primary display

* triple buffering is enabled in the driver (?)

Hi,
I am experiencing some quite annoying tearing on a video projector. I triggered the "sync" attribute of jit.gl.render with no succes. I think it might be an issue with the ATI Windows driver, though. If so, it might be hard to fix. Below is the list of hardware and software options we use. If anyone has an hint, it is more than welcome !!

---
HARDWARE LIST
 * PC with Intel Core 2 Duo (ASUS) on Windows XP SP2
 * ATI video card : ASUS EAH2900XT/G/HTVDI/512M
 * Projector : seems to do it on any one we tried. We are using the Christie DX+25 (as a second monitor)

SOFTWARE INFOS
 * Max/MSP + Jitter latest versions
 * I am using a lot jit.gl.lua, but it doesnt seem to make a difference
 * video driver : Catalyst Control Center (advanced)
 * refresh rate : 60Hz
 * the projector is not set as primary display
 * triple buffering is enabled in the driver (?)


tearing

> I am experiencing some quite annoying tearing on a video projector. I triggered the "sync" attribute of jit.gl.render with no succes. I think it might be an issue with the ATI Windows driver, though. If so, it might be hard to fix. Below is the list of hardware and software options we use. If anyone has an hint, it is more than welcome !!

> * PC with Intel Core 2 Duo (ASUS) on Windows XP SP2

> * ATI video card : ASUS EAH2900XT/G/HTVDI/512M

> * Projector : seems to do it on any one we tried. We are using the Christie DX+25 (as a second monitor)

> * I am using a lot jit.gl.lua, but it doesnt seem to make a difference

> * video driver : Catalyst Control Center (advanced)

> * the projector is not set as primary display

> * triple buffering is enabled in the driver (?)

On 9/13/07, Alexandre Quessy  wrote:
>
> Hi,
> I am experiencing some quite annoying tearing on a video projector. I triggered the "sync" attribute of jit.gl.render with no succes. I think it might be an issue with the ATI Windows driver, though. If so, it might be hard to fix. Below is the list of hardware and software options we use. If anyone has an hint, it is more than welcome !!
>
> Thanks,
> a
>
>
> ---
> HARDWARE LIST
>  * PC with Intel Core 2 Duo (ASUS) on Windows XP SP2
>  * ATI video card : ASUS EAH2900XT/G/HTVDI/512M
>  * Projector : seems to do it on any one we tried. We are using the Christie DX+25 (as a second monitor)
>
> SOFTWARE INFOS
>  * Max/MSP + Jitter latest versions
>  * I am using a lot jit.gl.lua, but it doesnt seem to make a difference
>  * video driver : Catalyst Control Center (advanced)
>  * refresh rate : 60Hz
>  * the projector is not set as primary display
>  * triple buffering is enabled in the driver (?)
>
>


Yes ! Both jit.gl.render and jit.window have @sync 1.

you don't mention if you are playing video or generating graphics. if you are playing video, are you sure that the tearing isn't in the source video?

you don't mention if you are playing video or generating graphics.  if you are playing video, are you sure that the tearing isn't in the source video?  

By default, jit.window @sync is 1, jit.gl.render @sync has no effect 

(legacy junk....sorry for any confusion).

On some windows graphics cards/drivers, users have reported the 

elimination of tearing when the window spans the two monitors (even 

if you just make a borderless window that has a few pixels on the 

main display). I'm not sure if that will work for your needs or not. 

Another thing to try might be to change the desktop spanning mode.

By default, jit.window @sync is 1, jit.gl.render @sync has no effect  
(legacy junk....sorry for any confusion).

On some windows graphics cards/drivers, users have reported the  
elimination of tearing when the window spans the two monitors (even  
if you just make a borderless window that has a few pixels on the  
main display). I'm not sure if that will work for your needs or not.  
Another thing to try might be to change the desktop spanning mode.

Thanks for the answers. The terrible tearing still occurs with a very simple patch like the one below. I guess I will file a bug report. I will try with only one monitor as soon as possible. (as this is using two monitor). I don't want to go fullscreen, because I need some feedback, and I want the grabbed frame buffer to be the same size than the window I render, and I don't want the render to use the full size of the projector...

You can use fullscreen and still render at a lower resolution. I do

this quite often to selectively downsample particular parts of the

scene for performance reasons. The way to do this is to render to a

texture and then display the texture on a full screen quad i.e.

jit.gl.videoplane @transform_reset 2. Andrew has posted some recipes

recently on render to texture using a patcher. Render to texture is

also quite easy to do using jit.gl.lua which you mentioned was part of

> Thanks for the answers. The terrible tearing still occurs with a very simple patch like the one below. I guess I will file a bug report. I will try with only one monitor as soon as possible. (as this is using two monitor). I don't want to go fullscreen, because I need some feedback, and I want the grabbed frame buffer to be the same size than the window I render, and I don't want the render to use the full size of the projector...

> #P message 42 278 74 9109513 position $1 $1 0;

> #P newex 42 299 224 9109513 jit.gl.gridshape bogus @shape plane @scale 0.5 0.5 1 1 @color 1 0 0 @depth_enable 0 @blend enable 1;

> #P newex 21 82 73 9109513 qmetro 16.6667;

> #P newex 21 103 53 9109513 t b b erase;

> #P newex 21 134 222 9109513 jit.gl.render bogus @erase_color 0. 0 0. 1. @ortho 2 @depth_enable 0 @antialias 1 @fsaa 6 @sync 1;

> #P newex 21 169 395 9109513 jit.window bogus @rect 1808 0 2576 768 @border 0 @interp 1 @floating 1 @fsaa 6 @sync 1;

> #P comment 106 63 287 9109513 The terrible tearing still occurs with a very simple patch like this !;

You can use fullscreen and still render at a lower resolution.  I do
this quite often to selectively downsample particular parts of the
scene for performance reasons.  The way to do this is to render to a
texture and then display the texture on a full screen quad i.e.
jit.gl.videoplane @transform_reset 2.  Andrew has posted some recipes
recently on render to texture using a patcher.  Render to texture is
also quite easy to do using jit.gl.lua which you mentioned was part of
your patch.

On 9/13/07, Alexandre Quessy  wrote:
>
> Thanks for the answers. The terrible tearing still occurs with a very simple patch like the one below. I guess I will file a bug report. I will try with only one monitor as soon as possible. (as this is using two monitor). I don't want to go fullscreen, because I need some feedback, and I want the grabbed frame buffer to be the same size than the window I render, and I don't want the render to use the full size of the projector...
>
> Cheers,
>
> a
> ~~~~~~~~~~~~~~
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 42 252 27 9109513 - 0.5;
> #P message 42 278 74 9109513 position $1 $1 0;
> #P newex 42 227 27 9109513 % 1.;
> #P newex 78 202 34 9109513 + 0.01;
> #P newex 42 202 27 9109513 f 0.;
> #P window linecount 2;
> #P newex 42 299 224 9109513 jit.gl.gridshape bogus @shape plane @scale 0.5 0.5 1 1 @color 1 0 0 @depth_enable 0 @blend enable 1;
> #P toggle 21 65 15 0;
> #P window linecount 1;
> #P newex 21 43 56 9109513 loadmess 1;
> #P newex 21 82 73 9109513 qmetro 16.6667;
> #P newex 21 103 53 9109513 t b b erase;
> #P window linecount 2;
> #P newex 21 134 222 9109513 jit.gl.render bogus @erase_color 0. 0 0. 1. @ortho 2 @depth_enable 0 @antialias 1 @fsaa 6 @sync 1;
> #P window linecount 1;
> #P newex 21 169 395 9109513 jit.window bogus @rect 1808 0 2576 768 @border 0 @interp 1 @floating 1 @fsaa 6 @sync 1;
> #P comment 106 63 287 9109513 The terrible tearing still occurs with a very simple patch like this !;
> #P connect 5 0 6 0;
> #P connect 6 0 4 0;
> #P connect 4 0 3 0;
> #P connect 3 0 2 0;
> #P connect 3 2 2 0;
> #P connect 3 1 8 0;
> #P connect 8 0 10 0;
> #P connect 10 0 12 0;
> #P connect 12 0 11 0;
> #P connect 11 0 7 0;
> #P connect 9 0 8 1;
> #P connect 8 0 9 0;
> #P window clipboard copycount 13;
>
>


correction : it seems like the grabbed pixels buffer is always the same size than the jit.window, even if the ji.gl.render is smaller than the same window. As I need the buffer texture to match the render size, I needed to use a smaller window than the full screen resolution (since our render area is a square). Is this correct ?

I'm missing something here. I don't quite follow your post. How are

you grabbing the pixels? jit.window's size should be the only one

you're concerned with. I don't really understand what you mean by

jit.gl.render is smaller than the same window.

> correction : it seems like the grabbed pixels buffer is always the same size than the jit.window, even if the ji.gl.render is smaller than the same window. As I need the buffer texture to match the render size, I needed to use a smaller window than the full screen resolution (since our render area is a square). Is this correct ?

I'm missing something here.  I don't quite follow your post.  How are
you grabbing the pixels?  jit.window's size should be the only one
you're concerned with.  I don't really understand what you mean by
jit.gl.render is smaller than the same window.

On 9/13/07, Alexandre Quessy  wrote:
>
> correction : it seems like the grabbed pixels buffer is always the same size than the jit.window, even if the ji.gl.render is smaller than the same window. As I need the buffer texture to match the render size, I needed to use a smaller window than the full screen resolution (since our render area is a square). Is this correct ?
>
> a
>


Tearing :-(