maybe do

while (isRunning())
{
if (_textureRenderer->_imageStream->getLoopingMode() ==
osg::ImageStream::LOOPING)
....

instead

Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey

On Wed, Jan 6, 2010 at 8:47 PM, Trajce Nikolov <[email protected]>wrote:

> Hi Robert,
>
> I did quick test with the WaitForCompletition and it works !!! Nise catch.
> Here is the code of the Thread::run
>
> void DirectShowImageStreamObserverThread::run()
> {
> if (_textureRenderer->_imageStream->getLoopingMode() ==
> osg::ImageStream::LOOPING)
> {
>  while (1)
> {
> long evCode = 0;
>  HRESULT hr = _textureRenderer->_mediaEvent->WaitForCompletion(INFINITE,
> &evCode);
>
> _textureRenderer->_imageStream->seek(0);
> _textureRenderer->_imageStream->play();
>  testCancel();
> }
> }
> }
>
> >Potentially we could tweak osg::Image to have
> a bool requiresUpdateCall() that tells the Texture classes whether
> Image::update needs to be called,
>
> This is what I had in mind when I started the thread about this., It would
> be very helpful if we extend the Image class to support this flag and gets
> updated atomaticaly.
>
> Nick
>
> http://www.linkedin.com/in/tnick
> Sent from Devlet, Ankara, Turkey
>
> On Wed, Jan 6, 2010 at 7:58 PM, Robert Osfield 
> <[email protected]>wrote:
>
>> HI Nick,
>>
>> > Hi Robert,
>> > yes, that was the place I started implementing the check there, however,
>> in
>> > there , DoRenderSample, the EC_COMPLETED is not fired.
>>
>> I was wondering if this might happen - the event fired after one gets
>> the frame is updated. Oh well nice try anyway :-)
>>
>> > I did quite a good
>> > search for this, looked in the SDK samples the code is originated from,
>> and
>> > they have it checking outside in the render loop. So I did it like this.
>> > Probably good solution is to make it like in the ImageSequence, to use
>> the
>> > update callback. What you think?
>>
>> I've just done quick search of the IID_IMediaEvent online and come
>> across MS docs on directshow that discuss the how to handle the events
>> in various ways.  It looks like you can tell directshow to dispatch a
>> windows event to your applications windows and have the event checked
>> for here, but this requires a handle to the window, which you don't
>> have in the plugin, so really a promising lead.
>>
>> The other item that the approach of using WaitForCompletion in a
>> separate thread that blocks till the the video is complete.  From the
>> msdocs at:
>>
>>   http://msdn.microsoft.com/en-us/library/dd389098%28VS.85%29.aspx
>>
>> > When the filter graph runs, data moves through the filters and is
>> rendered as video and
>> > audio. Playback occurs on a separate thread. You can wait for playback
>> to complete by
>> > calling the IMediaEvent::WaitForCompletion method:
>> >
>> > long evCode = 0;
>> > pEvent->WaitForCompletion(INFINITE, &evCode);
>> >
>> > This method blocks until the file is done playing, or until the
>> specified time-out interval
>> >  elapses. The value INFINITE means the application blocks indefinitely
>> until the file is done
>> > playing. For a more realistic example of event handling, see Responding
>> to Events.
>>
>> This would still require a dedicated thread to spawed just to wait
>> till the rendering is complete, but at least it should sit there
>> consuming little or no CPU resources till it gets awoken so might be
>> marginally better than your original solution of polling for the
>> events.
>>
>> Finally the approach of overriding Image::update(..) is an
>> possibility, I don't recall the details of ImageSequence so browsing
>> through the headers of ImageSequence we find the helper callback class
>> that enables the calling of the Image::update(..) from the update
>> traversal virtue of a StateAttributeAttribute callback that needs to
>> be attached to the Texture that the image is attached to, without this
>> callback the Image::update(..) isn't ever called:
>>
>>        struct OSG_EXPORT UpdateCallback : public
>> osg::StateAttributeCallback
>>        {
>>            virtual void operator () (osg::StateAttribute* attr,
>> osg::NodeVisitor* nv);
>>        };
>>
>> That is implemented in src/osg/ImageSquence.cpp thus:
>>
>> void ImageSequence::UpdateCallback::operator () (osg::StateAttribute*
>> attr, osg::NodeVisitor* nv)
>> {
>>    osg::Texture* texture = attr ? attr->asTexture() : 0;
>>
>>    //
>> osg::notify(osg::NOTICE)<<"ImageSequence::UpdateCallback::"<<texture<<std::endl;
>>    if (texture)
>>    {
>>        for(unsigned int i=0; i<texture->getNumImages(); ++i)
>>        {
>>            texture->getImage(i)->update(nv);
>>        }
>>    }
>> }
>>
>> And another bit of hacky code magic that glues things together
>> automatically can be found in src/osg/Texture2D.cpp - note the
>> attachment of the ImageSequence::UpdatecCallback() automatically:
>>
>> void Texture2D::setImage(Image* image)
>> {
>>    if (_image == image) return;
>>
>>    if (dynamic_cast<osg::ImageSequence*>(_image.get()))
>>    {
>>        setUpdateCallback(0);
>>        setDataVariance(osg::Object::STATIC);
>>    }
>>
>>    _image = image;
>>    _modifiedCount.setAllElementsTo(0);
>>
>>    if (dynamic_cast<osg::ImageSequence*>(_image.get()))
>>    {
>>        setUpdateCallback(new ImageSequence::UpdateCallback());
>>        setDataVariance(osg::Object::DYNAMIC);
>>    }
>> }
>>
>> Now the DirectShowImageStream won't trigger this automatically
>> callback attachment, so you'd have to manually attach this callback to
>> the textures you want.  Potentially we could tweak osg::Image to have
>> a bool requiresUpdateCall() that tells the Texture classes whether
>> Image::update needs to be called, rather than relying upon the hacky
>> dynamic_cast above. Personally I think this is something that would be
>> appropriate regardless of this DirectShowIssue as it just feels like a
>> better solution than present hack for ImageSequence.
>>
>> Thoughts?
>> Robert.
>> _______________________________________________
>> osg-submissions mailing list
>> [email protected]
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to