hello,
well, having 2 pd instance will create more problem that it will solve in this situation.
and this can't be share between cpu.
one possible optimisation is using pix_resize/pix_dump to output all data as a list that can be put on a table. pix_data will make as many call as pixel, but the pix_dump will make only 1 call to the gpu. it look like it work a bit better, but i did not really benchmark it. (since that's not where the bottleneck is)
i'm however disappointed that destroying / creating a new object is faster than changing an object colour.
cheers c
Le 25/06/2013 11:16, Philippe Boisnard a écrit :
Hello
To continue this question, perhaps, this preview can be create between 2 instances of puredata, with sharemem to transmit data colours. In this case, we ll no cpu problem for the first instance. and only preview-process in the second. I try to create that this week to explore this solution. In this case, it will be possible to have better preview quality. isn't it ?
best
p
Le 25 juin 2013 à 10:58, Cyrille Henry a écrit :
hello,
thanks for the patch, unfortunately, i think it's still too slow to be usable.
better than deleting everything and creating them back with new colour, i tried to change colours of the existing one. i tried with both the canvas version and the data structure version. in both case, things are lot's faster in the original patch than in my optimized version. that's not what i was expecting.
how come that it's faster to delete a canvas and create a new one than changing a canvas colour? (same question for data structure).
cheers c
Le 24/06/2013 20:31, Philippe Boisnard a écrit :
Le 24 juin 2013 à 20:20, Cyrille Henry a écrit :
i can see the discution, but where is the patch? and is it fast enough to be usable?
cheers c
Le 24/06/2013 19:31, Philippe Boisnard a écrit :
Yes
arnaud courcelles have made today with datastructures you can find this on codelab.fr on this thread http://codelab.fr/4343
Le 24 juin 2013 à 18:25, Cyrille Henry a écrit :
hello, it would really be useful to have an efficient pix_preview. did anyone try using data structure? would it be faster?
i guess lluis pix_preview is the best option for now
cheers c
Le 23/06/2013 22:31, Olivier Baudu a écrit : > I've received few messages asking me if it's a joke... :-° > > Well... > It's a kind of joke because it is useless... > (I redraw the GEM stream in hundred of 2x2 canvas) > > But it's not joke in the way that it really works on my laptop / Linux Mint DE / Pd-extended 0.43.4 / GEM 0.93 at 4 fps... > > Sorry if I've crashed your OS with my stuff... > > Cheers... > > 01ivier > > Le 23.06.2013 17:33, Olivier Baudu a écrit : >> Hi list, >> >> I want to share with you a big victory for me... :-p >> I've succeeded in visualizing image/video GEM stream inside my patch >> (at 4 fps !!). >> >> Well... >> You can't really do anything else when the automatic mode is on... :-D >> ... but I'm so proud, you know. >> >> Patch attached. >> Screenshot here : http://codelab.fr/4343#p23267 >> >> Cheers >> >> 01ivier >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list