Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance test playback window should close on stop #308

Open
mirh opened this issue Apr 18, 2017 · 6 comments
Open

Performance test playback window should close on stop #308

mirh opened this issue Apr 18, 2017 · 6 comments

Comments

@mirh
Copy link

mirh commented Apr 18, 2017

IMHO.
I totally don't see the point in a black window standing still there.

@mikecopperwhite
Copy link
Collaborator

Thanks for the report.

Again this seems to be the standard windowing behaviour for some video renderer filters. AFAICT it's up to the filter how to manage any created windows. Most system renderers leave the windows visible when stopping. Not something GSN can change really.

@mirh
Copy link
Author

mirh commented Apr 19, 2017

Well, doesn't graphstudio know when benchmark has ended?
I mean, this is not "our" actual technical problem then, but since for the love of me I cannot see a single case where keeping said window open would matter.. Can't we just kill it?

@mikecopperwhite
Copy link
Collaborator

mikecopperwhite commented Apr 20, 2017

If this was a standalone application then what you say makes perfect sense.

However GSN is a testbed application for DirectShow developers testing graphs and filters. On the whole GSN tries not to override default filter behaviour without showing some sort of UI cue that the behaviour has been customised by the application. When we start getting too clever it can interfere with this purpose. For example in #issue 291 GSN was doing something custom and non-standard with clock setting on new graphs which caused incorrect behaviour and needed to be removed.

You could add an option on the dialog for closing the video renderer window at the end of performance testing (the performance testing dialog knows when this happens) but it would probably involve querying for video renderer specific COM interfaces to get the window handle or some sort of hacky search for a window with a specific window title or window class and would only work with specific video renderers. What would happen with other video renderers that play full screen or use multiple or no windows or actually display meaningful images after playback has stopped? It seems niche and bit dirty to me...

@mirh
Copy link
Author

mirh commented Apr 20, 2017

Mhh, I totally see your point and I'd even close the issue now then.
But first, I wonder if at least in the case of LAV (where people owns sauces!) pinging their guys for an opinion would be worth it?

I mean, if not to cross-check what you said, at least to know if on their part anybody would mind to implement some.. stupidity to fix this even stupider nuisance.

@mikecopperwhite
Copy link
Collaborator

I'm guessing here you mean the 'LAV video decoder' filter. I'm not aware of an LAV video renderer filter.

Changing the LAV video decoder filter wouldn't help as the playback window is created and destroyed by the renderer filter and is independent of the decoder filter that's being used. The DirectShow architecture deliberately limits the extent of interactions between filters (and that's a very good thing!).

@mirh
Copy link
Author

mirh commented Apr 21, 2017

I'm guessing here you mean the 'LAV video decoder' filter. I'm not aware of an LAV video renderer filter.

Yes, sorry if I confuse labels.

Changing the LAV video decoder filter wouldn't help as the playback window is created and destroyed by the renderer filter and is independent of the decoder filter that's being used.

Ohh, I see. I wonder if we couldn't workaround it somehow else "externally" (ie not touching directshow) then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants