Roman Haefeli a écrit :
...
this jitter make it impossible to compute 1 and only 1 frame for each frame
on the screen, even with sync on vblank.
yo, i trapped my self by measuring with [timer].
anyway, if you calculate the average of these values, you'll come pretty
close to 50ms
hello,
i'm not 100% sur i agree with your analyse.
could you test the same patch without Vsync?
if the driver wait for the no load, introducing a 26ms frame.
the next no load will be 1 frame latter: i.e. 16.6ms
but the next frame is 6ms latter.
i'm wondering if the explanation is not :
16ms
On Fri, 12 Oct 2007, chris clepper wrote:
On 10/12/07, chris clepper [EMAIL PROTECTED] wrote:
On 10/12/07, Mathieu Bouchard [EMAIL PROTECTED] wrote:
Ok, then the only solution is to start a small thread that only tries to
display the last completed frame. It's sort of like the threaded
Le jeudi 11 octobre 2007 à 15:32 -0400, Thomas O Fredericks a écrit :
Yes there is.
Your monitors have to have the same refresh rate in your xorg.conf (for all
your monitors)
do you mean this part of xorg.conf:
Section Monitor
Identifier builtin
Option DPMS
BOTH screens must have the same refresh rate or you will get tearing.
Tom
On 10/12/07, Olivier Heinry [EMAIL PROTECTED] wrote:
Le jeudi 11 octobre 2007 à 15:32 -0400, Thomas O Fredericks a écrit :
Yes there is.
Your monitors have to have the same refresh rate in your xorg.conf (for
all
Roman Haefeli a écrit :
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
sync to vblank will sync swapping buffer with the screen frame rate, but
that's not the original question.
to my knowledge, there is no possibility to sync gem rendering with the
On 10/12/07, Mathieu Bouchard [EMAIL PROTECTED] wrote:
Is it possible to make the frame-display call non-blocking ?
Just like when you read from or write to a socket with O_NONBLOCK so that
it returns immediately, or use SIGALRM to put a timeout on a read or write
operation.
This used to
On Fri, 12 Oct 2007, chris clepper wrote:
This used to be an option on the Mac, but it stopped working at some
point. It might have to do with the fact that all windows in the manager
are locked to VBL already. Other OS might do it differently when just
one GL app is set to sync.
Ok, then
On Fri, 12 Oct 2007, chris clepper wrote:
Note that every other frame pattern. Why is that? The low number is
probably a fairly accurate number for the CPU to fetch the frame from disk,
decode and then fling it up onto the GPU for texturing, but what about the
other number? Add the two
There is one catch to using vsync that not many know about. This
illustrates it pretty well:
[gemwin 60] with pix_movie playing back a 29.97 fps DV clip:
print: 6.001
print: 27.532
print: 5.823
print: 27.144
print: 6.313
print: 27.383
print: 5.992
print: 28.492
print: 4.613
print: 29.411
print:
Also, this isn't really a problem to being with. There is enough time to
complete the calls and it runs at the correct Quicktime framerate and the
request GL one too.
On 10/12/07, chris clepper [EMAIL PROTECTED] wrote:
On 10/12/07, Mathieu Bouchard [EMAIL PROTECTED] wrote:
Ok, then the
On 10/12/07, Mathieu Bouchard [EMAIL PROTECTED] wrote:
Ok, then the only solution is to start a small thread that only tries to
display the last completed frame. It's sort of like the threaded
soundfiler.
Threading and OpenGL are a no-no. Plus, the driver is just going to stall
on all GL
On Fri, 2007-10-12 at 20:17 +0200, cyrille henry wrote:
Roman Haefeli a écrit :
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
sync to vblank will sync swapping buffer with the screen frame rate, but
that's not the original question.
to my
Hi,
A friend from our schools psychology department wants to use PD and GEM
for an experiment. Here is his question and attached is the example
patch. We need you help on this. Thanks.
-
OK, this is the patch that I'm going to use to conduct a research on
Batuhan Bozkurt wrote:
So the required stimuli are a beep sound (which is a 3.5khz sine with
7 ms duration) and a flash (which is basically a white circle visible
only for 20ms).
The problem is, it is very hard for an object to flash with this short
duration. If you look at the patch
set the framerate of your gemwin higher, then you get a flash at
every bang.
change
[gemwin]
to
[gemwin 80]
(default with no argument is 20)
m.
Am 11.10.2007 um 12:42 schrieb Batuhan Bozkurt:
#N canvas 78 53 295 395 10;
#X obj 13 248 gemhead;
#X msg 101 259 0 0 0;
#X obj 13 311 disk 3
You need to raise the gemwin framerate. Just create the object like this:
[gemwin 50] and you should see all of the flashes. Also, setting the gemwin
to the refresh rate of the display might be best.
On 10/11/07, Batuhan Bozkurt [EMAIL PROTECTED] wrote:
Hi,
A friend from our schools
chris clepper wrote:
You need to raise the gemwin framerate. Just create the object like
this: [gemwin 50] and you should see all of the flashes. Also,
setting the gemwin to the refresh rate of the display might be best.
That easy... Thanks it works properly now!
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the
screen refresh rate?
i noticed, that when using [gemwin screenrefreshrate],
Yes there is.
Your monitors have to have the same refresh rate in your xorg.conf (for all
your monitors) as Gems refresh rate and you have to set up the opengl params
of your card so that it refreshes the opengl in between synchs (called sync
to VBlank in my nvidia-settings panel).
On 10/11/07,
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the
screen refresh rate?
i noticed, that when using
Batuhan Bozkurt a écrit :
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the
gem-rendering.
while we are at: is there some way to hardsync Gem's framerate with the
screen refresh
sync to vblank will sync swapping buffer with the screen frame rate, but
that's not the original question.
to my knowledge, there is no possibility to sync gem rendering with the
screen frame rate.
if you fix both at 60Hz, you can have jitter (not a lot, but some).
You are not technically syncing
Thomas O Fredericks a écrit :
sync to vblank will sync swapping buffer with the screen frame rate, but
that's not the original question.
to my knowledge, there is no possibility to sync gem rendering with the
screen frame rate.
if you fix both at 60Hz, you can have jitter (not a lot, but
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
sync to vblank will sync swapping buffer with the screen frame rate, but
that's not the original question.
to my knowledge, there is no possibility to sync gem rendering with the
screen frame rate.
On Thu, 2007-10-11 at 22:53 +0300, Batuhan Bozkurt wrote:
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the
gem-rendering.
while we are at: is there some way to hardsync Gem's
On Fri, 2007-10-12 at 01:49 +0200, Roman Haefeli wrote:
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
sync to vblank will sync swapping buffer with the screen frame rate, but
that's not the original question.
to my knowledge, there is no
I agree!
It would guarentee better results but would increase the chance of a cpu
lock up I think!
Tom
On 10/11/07, Roman Haefeli [EMAIL PROTECTED] wrote:
On Fri, 2007-10-12 at 01:49 +0200, Roman Haefeli wrote:
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks
There is no clock available from the GPU.
On 10/11/07, Roman Haefeli [EMAIL PROTECTED] wrote:
but for many other applications it would be better (read: the result
would look nicer), if [gemhead] would get it's tick from the gpu and not
from pd/audiocard, i think.
is that something that
On Thu, 2007-10-11 at 19:39 -0500, chris clepper wrote:
There is no clock available from the GPU.
yo, sorry, i am just guessing 'into the blue'. i actually don't know,
from where the screen gets its clock.
but you sure understand, what i mean. whereever from the screen gets its
clock to, it
On Thu, 2007-10-11 at 20:34 -0400, Thomas O Fredericks wrote:
I agree!
It would guarentee better results but would increase the chance of a
cpu lock up I think!
yo, i don't know anyhting about how these things are handled internally,
but i wonder, what makes you think that.
roman
The next time i will ask to my gpu what time is it ! We'll see.
Jack
Le 12 oct. 07 à 02:39, chris clepper a écrit :
There is no clock available from the GPU.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
On Fri, 2007-10-12 at 02:08 +0200, Roman Haefeli wrote:
On Thu, 2007-10-11 at 22:53 +0300, Batuhan Bozkurt wrote:
Roman Haefeli wrote:
On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote:
the next thing is to synchronize your trigger events with the
gem-rendering.
On 10/11/07, Roman Haefeli [EMAIL PROTECTED] wrote:
On Thu, 2007-10-11 at 19:39 -0500, chris clepper wrote:
There is no clock available from the GPU.
yo, sorry, i am just guessing 'into the blue'. i actually don't know,
from where the screen gets its clock.
The display device has an
34 matches
Mail list logo
