Tearing :-(

Sep 13, 2007 at 2:32pm

Tearing :-(

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

#33657
Sep 13, 2007 at 2:37pm

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

#112397
Sep 13, 2007 at 5:39pm

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

a

#112398
Sep 13, 2007 at 6:51pm

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

#112399
Sep 13, 2007 at 7:21pm

#112400
Sep 13, 2007 at 7:28pm

#112401
Sep 13, 2007 at 7:36pm

#112402
Sep 13, 2007 at 8:04pm

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

#112403
Sep 13, 2007 at 10:01pm

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;

#112404
Sep 13, 2007 at 10:08pm

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

#112405
Sep 13, 2007 at 10:10pm

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

#112406
Sep 13, 2007 at 10:17pm

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
>

#112407

You must be logged in to reply to this topic.