[PD] Gem frame rate over 60fps

[IOhannes m zmoelnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180905/38b011ca/attachment.sig>