Does using [auto $1< to play a video file with pix_film take less CPU than a counter that increments with every render?
Thanks
Tom
On 11/28/05, Thomas Ouellet Fredericks iamonthebeach@gmail.com wrote:
Does using [auto $1< to play a video file with pix_film take less CPU than a counter that increments with every render?
On which platform? The answer is often 'yes' on OSX.
cgc
chris clepper wrote:
On 11/28/05, Thomas Ouellet Fredericks iamonthebeach@gmail.com wrote:
Does using [auto $1< to play a video file with pix_film take less CPU than a counter that increments with every render?
On which platform? The answer is often 'yes' on OSX.
and on linux + w32 it is 'no' (being merely a shortcut for building your own counter)
mfg.adsr. IOhannes
hi,
Does using [auto $1< to play a video file with
pix_film take less CPU
than a counter that increments with every render?
On which platform? The answer is often 'yes' on
OSX. and on linux + w32 it is 'no' (being merely a shortcut for building your own counter)
However, I found that pix_film seems to decode frame(s) anytime a render command arrives at its inlet, even if it is the same frame as with the last render command (bah, twisted explanation ... ) i therefore made myself a little subpatch that decodes frames only if they are different from the one decoded at the last render command (using pix_buffer), which proved to cut cpu usage by half or so, depending on the frame rates. Thinking about this again - could it be that uploading a texture to the gpu takes up some cpu cycles as well? pix_buffer prevents these transfers as well, iirc.
hope I'm making sense here, thoralf.
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Thoralf Schulze wrote:
hi,
Does using [auto $1< to play a video file with
pix_film take less CPU
than a counter that increments with every render?
On which platform? The answer is often 'yes' on
OSX. and on linux + w32 it is 'no' (being merely a shortcut for building your own counter)
However, I found that pix_film seems to decode frame(s) anytime a render command arrives at its inlet, even if it is the same frame as with the last render command (bah, twisted explanation ... )
is it? this would be bad (unless i thought of something very cool when i modified the sources to behave like that...)
the CVS versions of [pix_film]/[pix_movie] are now threaded and should behave much better. however it uses pthreads, so it is likely to not work with a standard windows build (but i guess you could do that with mingw)
Thinking about this again - could it be that uploading a texture to the gpu takes up some cpu cycles as well?
it surely does.
pix_buffer prevents these transfers as well, iirc.
it surely does not, unless i am totally mistaken.
if the image changes (or Gem _thinks_ that the image has changed) then it will be uploaded. in pix_film, everytime a "new" frame is grabbed, it is assumed that it changed. so when the decoding is done each render cycle, Gem eventually thinks that the image changed each render cycle and thus does duplicate texture uploads.
so fixing the duplicate decoding should help in both cases.
(now that i rethink it, i remember that for certain decoding APIs (namely mpeg, streams,...), the given frame-number does not necessarily correspond to the decoded frame-number...anyhow, this is why decided to let the decoder (e.g. filmAVI) decide whether it would want to re-decode the stream or not)
mfg.asdr IOhannes
Hallo!
the CVS versions of [pix_film]/[pix_movie] are now threaded and should behave much better. however it uses pthreads, so it is likely to not work with a standard windows build (but i guess you could do that with mingw)
why should it not work on windows? even pd uses pthreads, also on windows. And it can be compiled with msvc and MinGW (but you will need different dlls) ...
LG Georg
Georg Holzmann wrote:
Hallo!
the CVS versions of [pix_film]/[pix_movie] are now threaded and should behave much better. however it uses pthreads, so it is likely to not work with a standard windows build (but i guess you could do that with mingw)
why should it not work on windows? even pd uses pthreads, also on windows. And it can be compiled with msvc and MinGW (but you will need different dlls) ...
oops sorry
this should read: "however it uses pthreads, so i don't know whether this will work on a standard windows build (using msvc)"
i noticed that you were using pthreads on w32 with mingw; i was just unsure whether msvc supports them too (good if it does!)
fmg.asdr. IOhannes
On Nov 29, 2005, at 11:07 AM, IOhannes m zmoelnig wrote:
Georg Holzmann wrote:
Hallo!
the CVS versions of [pix_film]/[pix_movie] are now threaded and
should behave much better. however it uses pthreads, so it is likely
to not work with a standard windows build (but i guess you could do
that with mingw)why should it not work on windows? even pd uses pthreads, also on
windows. And it can be compiled with msvc and MinGW (but you will need
different dlls) ...oops sorry
this should read: "however it uses pthreads, so i don't know whether
this will work on a standard windows build (using msvc)"i noticed that you were using pthreads on w32 with mingw; i was just
unsure whether msvc supports them too (good if it does!)
Yes, that's what Miller uses to compile Pd on Windows with MSVC.
.hc
fmg.asdr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
-
chris clepper -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Thomas Ouellet Fredericks -
Thoralf Schulze