Forums > Jitter

Tearing :-(

September 13, 2007 | 2:32 pm

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 (?)


September 13, 2007 | 2:37 pm

did you try @sync 1 with jit.window?

wes

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 (?)
>
>


September 13, 2007 | 5:39 pm

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

a


September 13, 2007 | 6:51 pm

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?

p


September 13, 2007 | 7:21 pm


September 13, 2007 | 7:28 pm


September 13, 2007 | 7:36 pm


September 13, 2007 | 8:04 pm

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.

-Joshua


September 13, 2007 | 10:01 pm

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;


September 13, 2007 | 10:08 pm

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.

wes

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;
>
>


September 13, 2007 | 10:10 pm

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


September 13, 2007 | 10:17 pm

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.

wes

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
>


Viewing 12 posts - 1 through 12 (of 12 total)