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
