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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list