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
so
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 :
16m
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 50
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.
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
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, th
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 t
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 u
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 number
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:
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
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
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
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 ha
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
> > >
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 ->
http://lists.pureda
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
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
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 th
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
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, the
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
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
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, b
"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 syncin
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 th
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 [ge
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, Ro
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 ], both are quite
in
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!
__
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 ps
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
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
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
34 matches
Mail list logo