Hi all, I would like to know if there is a way to record a [gemframebuffer] into a [pix_buffer 1000] my goal is to be able to record a gemchain animation (5 seconds maybe) and replay it (forward, backward, etc) I know that [pix_snap] with [pix_buffer] could do the job, but it eat a lot of cpu, so a solution with [gemframebuffer] would be better...
pierre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-20 11:53, pierre@314r.net wrote:
Hi all, I would like to know if there is a way to record a [gemframebuffer] into a [pix_buffer 1000] my goal is to be able to record a gemchain animation (5 seconds maybe) and replay it (forward, backward, etc) I know that [pix_snap] with [pix_buffer] could do the job, but it eat a lot of cpu, so a solution with [gemframebuffer] would be better...
no. the problem you have is that you have to transfer whatever is rendered into a framebuffer (whether this is [gemframebuffer] or [gemwin] doesn't matter) back to main memory (which is what [pix_snap] does), and that is usually slow.
you might try to use a shader to transfer data within texture-memory (rather than between texture-memory and main-memory)
fgmasdr IOhannes
Hi IOhannes
On 2012-06-20 11:53, pierre@314r.net wrote:
Hi all, I would like to know if there is a way to record a [gemframebuffer] into a [pix_buffer 1000] my goal is to be able to record a gemchain animation (5 seconds maybe) and replay it (forward, backward, etc) I know that [pix_snap] with [pix_buffer] could do the job, but it eat a lot of cpu, so a solution with [gemframebuffer] would be better...
no. the problem you have is that you have to transfer whatever is rendered into a framebuffer (whether this is [gemframebuffer] or [gemwin] doesn't matter) back to main memory (which is what [pix_snap] does), and that is usually slow.
you might try to use a shader to transfer data within texture-memory (rather than between texture-memory and main-memory)
ok thanks, I will stay with [pix_snap] for now, on a good computer it could works,
but I'll try also the shader solution
p.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-20 12:54, pierre@314r.net wrote:
ok thanks, I will stay with [pix_snap] for now, on a good computer it could works,
"good computer" might help or not. more important is the gfx-card.
also, if you can live with a slightly async transfer (that introduces a delay) _and_ you are uisng a recent version of Gem (unstable!), you could try the "pbo" message to [pix_snap] which will use PBOs (hence the name) to do the image transfer which could be a lot faster than the default method of [pix_snap]. otoh, it could be slower as well. usage: [pbo $1( with "$1" being the number of PBOs to use for the transfer (0 disables PBO-transfers, anything more than 2 might not really give you any improvement)
fgamsdr Iohannes
but I'll try also the shader solution
p.
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello
Le 20/06/2012 13:35, IOhannes m zmoelnig a écrit :
also, if you can live with a slightly async transfer (that introduces a delay) _and_ you are uisng a recent version of Gem (unstable!), you could try the "pbo" message to [pix_snap] which will use PBOs (hence the name) to do the image transfer which could be a lot faster than the default method of [pix_snap]. otoh, it could be slower as well. usage: [pbo $1( with "$1" being the number of PBOs to use for the transfer (0 disables PBO-transfers, anything more than 2 might not really give you any improvement)
It look like this should be add on the pix_snap help file.
is there anything else to mention? cheers Cyrille
P.S. pbo 1 double frame rate when snapping big images on my computer. pbo 2 triple it.
Hi,
ok thanks, I will stay with [pix_snap] for now, on a good computer it could works,
"good computer" might help or not. more important is the gfx-card.
yes sure, and could I add to this list 'gfx-card drivers' my current setup is : debian/sid x86_64, gtx460m with proprietary drivers, Pd and Gem from latest sources (OffTopic : I want to use 'nouveau' but last time I used it, it was 2D only, any advise or experience with 'nouveau' welcome)
also, if you can live with a slightly async transfer (that introduces a delay) _and_ you are uisng a recent version of Gem (unstable!), you could try the "pbo" message to [pix_snap] which will use PBOs (hence the name) to do the image transfer which could be a lot faster than the default method of [pix_snap]. otoh, it could be slower as well. usage: [pbo $1( with "$1" being the number of PBOs to use for the transfer (0 disables PBO-transfers, anything more than 2 might not really give you any improvement)
fgamsdr Iohannes
Waouh, nice ! thanks for the trick ! I will try tonight and keep you informed, regards,
p.
-
Cyrille Henry -
IOhannes m zmoelnig -
Pierre -
pierre＠314r.net