[PD] Gem frame rate over 60fps

[Csaba Láng]

Iohannes,

thanks for your advice. However I forgot to add that the 200fps I would
like to use is not for displaying, but mostly to analyse fast objects in
front of the camera.
the chain would look like this:
[0( and [metro 5(
|
[gemhead]
|
[pix_video] with videoPYLON plugin
[pix_multiblob]

no pix_texture needed for video render, I use only the coordinates of the
centre of gravity.
Theoretically, it should use the capacity frame rate of the USB3 cameras,
should not it?

Best,
Popesz

On Wed, Sep 5, 2018 at 1:56 PM IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> On 2018-09-05 12:26, Csaba Láng wrote:
> > Dear list,
> > I am using high speed cameras with 200fps.
> > Is there any hard coded limitation in Gem which determines maximum fps?
>
> no
>
> > or [frame 200( to [gemwin] is enough?
>
> no
>
> > I tried [metro 5] to [gemhead] too, but need a proof that it goes 200fps.
> > Does any of you have a patch which could measure the fps in gemwin?
>
> measure the time between two render-ticks with [realtime].
>
>
> anyhow: the problem you are facing is, that Gem uses openGL to render to
> the [gemwin].
> depending on the driver and your driver settings, the openGL render
> buffer might only be swapped while the screen is being blanked
> ("sync-to-vblank"), to avoid tearing.
> if this is enabled, this means that for each render-tick, Gem (well,
> rather the underlying openGL engine) will wait for a vblank until the
> render-tick can be executed.
> the vblank happens whenever the screen is refreshed.
> if your screen has a refresh-rate of 97Hz, then the effective (maximum)
> frame-rate of the [gemwin] will be 97fps - regardless of what framerate
> you requested for the [gemwin] (via argument, or via the [frame(
> message). (pick *your* actual screen refresh rate).
> also, if the screen framerate is not an integer multiple of your chosen
> Gem-framerate, you might get weird resampling artifacts in the render
> timing.
>
> however, the only operations affected by this are openGL operations.
> these include all objects that draw to the screen (e.g. [square]), or
> manipulate the drawings (e.g. [rotate]) or the framebuffer
> ([gemframebuffer], [glsl_program], [pix_texture])
>
> on the other side, objects that do not interact with the openGL engine,
> are not directly affected.
> most importantly, grabbing image data ([pix_image], [pix_video],...),
> storing image data ([pix_buffer...]) and manipulating image data
> ([pix_gain], [pix_kaleidoscope], [pix_multiblob],...) has nothing to do
> with openGL and is therefore unaffected by sync-to-vblank.
>
> at least in theory. because when running a normal Gem-patch, the
> [pix_...] objects are driven (aka: triggered) by [gemwin], which (as it
> interacts with the openGL engine) is bound by sync-to-vblank.
>
> however: if (and only if) you have a [gemhead] that is only triggering
> non-openGL objects (e.g. *only* [pix_...]es), then you can manually
> trigger *this* gem-chain via a [metro], running at an arbitrary rate.
> (you should turn off the automatic-triggering of this [gemhead] by
> sending it a "0"),
>
>
>
> > I found something on the forum but not sure if it does the job for me.
>
> i found something in my washbasin, but i don't know how much i can
> charge for it.
>
>
> hgmasd
> rIOhannes
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180905/26be1d26/attachment-0001.html>