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

Texture support for glfw. #9822

Closed
wants to merge 33 commits into from
Closed

Conversation

cloudwebrtc
Copy link
Contributor

@cloudwebrtc cloudwebrtc commented Jul 13, 2019

PR for flutter/flutter#30718.
II tested RGB rendering under windows, tried window scaling, and the video showed everything is fine. But it seems that we need to add glad support to third_party/glfw/BULLD.gn.

Screenshot (Windows 10/ Ubuntu 16.04)

Merge pull request from flutter/engine
- Add Success and Error handler for EventSink.
- Send Event message or error using MethodCodec.
- Add GLFWPixelBuffer to manage Texture buffer copy.
- Remove unnecessary offscreen context in ExternalTextureGL.
- Create GL_TEXTURE_2D Texture using the height and width of GLFWPixelBuffer.
@cloudwebrtc
Copy link
Contributor Author

cloudwebrtc commented Jul 13, 2019

@chinmaygarde @stuartmorgan
It seems that we need to add glad_gl.c to the third_party/glfw/BULLD.gn of glfw, because texture rendering calls the function in glad.
https://fuchsia.googlesource.com/third_party/glfw/+/refs/heads/master/BUILD.gn#29

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few initial high-level comments.

@@ -0,0 +1,116 @@
// Copyright 2013 The Flutter Authors. All rights reserved.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please split event channel support out into a separate precursor PR to keep the scope smaller.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will submit event_channel.h in another PR.


namespace flutter {

template <typename T>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the things in this file need declaration comments, per Google's C++ style guide.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies to all of the class declarations, method declarations, and typedefs in this PR, not just this file.

shell/platform/glfw/external_texture_gl.h Outdated Show resolved Hide resolved
- Remove event_channel.h from this PR
- Remove the GLFW prefix for PixelBuffer.
- Remove event_channel.h from this PR
- Remove the GLFW prefix for PixelBuffer.
@stuartmorgan
Copy link
Contributor

@chinmaygarde @stuartmorgan
It seems that we need to add glad_gl.c to the third_party/glfw/BULLD.gn of glfw, because texture rendering calls the function in glad.
https://fuchsia.googlesource.com/third_party/glfw/+/refs/heads/master/BUILD.gn#29

I would expect that to be a separate target, rather than part of the GLFW target; I'm not sure why it was done that way in the Fuchsia build.

Also, adding that may require changes to the license script, as I remember that at least parts of deps had issues when I was initially adding GLFW.

@cloudwebrtc
Copy link
Contributor Author

Probably I got it wrong, I see engine/DEPS just checkout glfw source from Fuchsia, but compile it with buildroot/build/secondary/third_party/glfw/BUILD.gn.
It seems that we should add glad.c to https://github.com/flutter/buildroot/blob/c4df4a7b616f6ef1bc81bd99efdd4bff107a407e/build/secondary/third_party/glfw/BUILD.gn.
So maybe I should add a patch to flutter/buildroot.

@stuartmorgan
Copy link
Contributor

So maybe I should add a patch to flutter/buildroot.

That's what would be needed, yes, but my comment was to suggest that we should have a separate target for that, not fold it into the primary GLFW target as was done in the file you linked to.

Please test licenses locally before sending the buildroot patch though, so that it doesn't end up being something that prevents buildroot rolls and needs to be reverted (since the problem won't show up in CI until the PR that tries to roll buildroot forward).

- Add comments to related classes.
- Remove std::shared_ptr<> for PixelBuffer.
- Optimize texture rendering code.
@cloudwebrtc cloudwebrtc force-pushed the texture_glfw branch 2 times, most recently from da077a6 to 8b6234f Compare July 16, 2019 19:02
@cloudwebrtc
Copy link
Contributor Author

Fixed a few bugs and tested under Linux.

@lattice0
Copy link

I'm trying to run this pull request. I've been able to render a texture to screen by indirectly triggering MarkTextureFrameAvailable when I click on buttons or resize the screen.

If I call texture_registrar->MarkTextureFrameAvailable(texture_id_); I end up with this:

[FATAL:flutter/shell/common/shell.cc(808)] Check failed: task_runners_.GetPlatformTaskRunner()->RunsTasksOnCurrentThread().

it's worth noticing thattexture_registrar->MarkTextureFrameAvailable(texture_id_); only fails if called from another thread. However I don't see utility in calling it from the main thread, I need to call it fromt he thread that received video.

Is there something I'm missing? Is there a way to call MarkTextureFrameAvailable indirectly from another thread in a way that it's called from the main thread?

Thank you so much

(I'm also doing some modifications on the engine to render with arbitrary opengl calls, I guess it's going to be very useful for the community)

@stuartmorgan
Copy link
Contributor

it's worth noticing that [it] only fails if called from another thread.

Any embedder.h API that doesn't explicitly say otherwise must be called from the same thread as the engine was created on; that includes this one.

However I don't see utility in calling it from the main thread, I need to call it fromt he thread that received video.

If you have a use case where you are doing things on another thread, it's your responsibility to dispatch the calls to the correct thread.

Is there a way to call MarkTextureFrameAvailable indirectly from another thread in a way that it's called from the main thread?

There are a variety of ways to pass information between threads; that's off-topic for this PR though.

(I'm also doing some modifications on the engine to render with arbitrary opengl calls, I guess it's going to be very useful for the community)

I would encourage you to open a "Feature request" issue with your proposal for discussion before implementing a new feature in the engine.

@lattice0
Copy link

it's worth noticing that [it] only fails if called from another thread.

Any embedder.h API that doesn't explicitly say otherwise must be called from the same thread as the engine was created on; that includes this one.

However I don't see utility in calling it from the main thread, I need to call it fromt he thread that received video.

If you have a use case where you are doing things on another thread, it's your responsibility to dispatch the calls to the correct thread.

Is there a way to call MarkTextureFrameAvailable indirectly from another thread in a way that it's called from the main thread?

There are a variety of ways to pass information between threads; that's off-topic for this PR though.

(I'm also doing some modifications on the engine to render with arbitrary opengl calls, I guess it's going to be very useful for the community)

I would encourage you to open a "Feature request" issue with your proposal for discussion before implementing a new feature in the engine.

Thanks for the information. I spent the day thinking on how I could do that and couldn't end in a conclusion.

It seems that my only option is to run RunEventLoopWithTimeout in a while loop with a very small timeout (1 milissecond) and probe for MarkTextureFrameAvailable call from the thread but this seems innefficient. If I have 10 videos with 60fps then half a second could be spent checking for thse calls, I guess.

I also checked @cloudwebrtc's demo of RTC app and there's no custom event loop at all: https://github.com/cloudwebrtc/flutter-webrtc-demo/blob/desktop/linux/flutter_webrtc_demo.cc so I wondered how it's done. I gone and found how MarkTextureFrameAvailable is called: https://github.com/cloudwebrtc/flutter-webrtc/blob/desktop/common/src/flutter_video_renderer.cc#L90 but I couldn't find the thread which calls it, because there's lot of external libraries imvolved that I couldn't find. So, it looks like the plugin's thread is the one calling MarkTextureFrameAvailable, how is this possible?

@stuartmorgan
Copy link
Contributor

So, it looks like the plugin's thread is the one calling MarkTextureFrameAvailable, how is this possible?

Plugins don't intrinsically have their own threads, so it's not clear what you are asking here. They are constructed on, and receive method calls on, the same thread that is used for all other embedder API calls.

@lattice0
Copy link

So, it looks like the plugin's thread is the one calling MarkTextureFrameAvailable, how is this possible?

Plugins don't intrinsically have their own threads, so it's not clear what you are asking here. They are constructed on, and receive method calls on, the same thread that is used for all other embedder API calls.

I was analyzing how @cloudwebrtc's flutter-webrtc-demo does the MarkTextureFrameAvailable call and since it receives video through internet it must use a thread. The call happens here: https://github.com/cloudwebrtc/flutter-webrtc/blob/desktop/common/src/flutter_video_renderer.cc#L90 but I couldn't find which thread calls it so I suppose it's not the main thread. However it can't be possible, because MarkTextureFrameAvailable must be called from the main thread.

Anyways, is my only option to use RunEventLoopWithTimeout to probe for MarkTextureFrameAvailable calls on a queue?

@stuartmorgan
Copy link
Contributor

Again, how to write multi-threaded code using the GLFW embedding is off-topic for this PR; please find another forum for that conversation. The discussion here should be focused on the review of this PR and the process for getting it landed.

@cbracken
Copy link
Member

cbracken commented Nov 4, 2019

@chinmaygarde if you get a moment, would you mind taking a look?

@cloudwebrtc
Copy link
Contributor Author

@stuartmorgan Updated, please review. :)

@stuartmorgan
Copy link
Contributor

I'll do a full review of the changes when I get a chance, but this still need a review from @chinmaygarde.

@rao-subba-venkata
Copy link

Appreciate if I can get hint to play mp4 file for Linux or Windows Desktop.

@stuartmorgan
Copy link
Contributor

@venkata-subbarao As I said above: "The discussion here should be focused on the review of this PR and the process for getting it landed." This isn't the right place to ask for help using this API; please use a support forum for that.

or Windows

This PR is no longer relevant to Windows.

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just small things left from me.

Still needs a review from @chinmaygarde on the texture aspects.

// |height| and |width| parameters of bounds.
// In some cases, we need to scale the texture to the bounds size to reduce
// memory usage.
virtual const PixelBuffer* CopyPixelBuffer(size_t width, size_t height) = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still needs to be addressed.

@j4qfrost

This comment has been minimized.

@winwisely99
Copy link

@stuartmorgan

Polite ping to have a look again.

It looks like the pixel buffer pointer has been documented by @cloudwebrtc

@stuartmorgan
Copy link
Contributor

@winwisely99 As I said above, this needs a review from @chinmaygarde. Further review from me before then isn't going to advance this.

@andrewmd5
Copy link

Totally sympathetic to crazy times right now, but It would be great if @chinmaygarde was able to provide an update on their review as it seems there has been no immediate action and this pull is becoming stale.

If those conversations are happening elsewhere than I apologize.

@peerwaya
Copy link

@chinmaygarde Kindly update

@stuartmorgan
Copy link
Contributor

Now that both Windows and Linux have switched away from GLFW, I'm going to close this; while we still build the GLFW embedding for limited internal use, implementing this would no longer affect any of the embeddings used by the flutter tool.

@cloudwebrtc, if you are still interested in implementing this for GLFW for some reason despite that, please comment and I'll re-open, but the way to move forward to support a project like your plugin would be texture support for the Windows (Win32) and Linux (GTK) embeddings.

@lattice0
Copy link

@stuartmorgan I don't get it. Wasn't the goal to be independent from the GUI API? So both Qt, GTK, etc would work? Now GTK is chosen to be the default/official for linux then?

I thought GLFW was the right way as it would work with all of them, even had some modifications that could do YUV420P conversion in shader, I was about to finish it

@stuartmorgan
Copy link
Contributor

@stuartmorgan I don't get it. Wasn't the goal to be independent from the GUI API? So both Qt, GTK, etc would work? Now GTK is chosen to be the default/official for linux then?

This is covered (as it has always been) in the desktop documentation

I thought GLFW was the right way as it would work with all of them

GLFW didn't work with any of them; neither add-to-app nor PlatformView were viable with GLFW. The documentation has always been very clear that the GLFW embedding was a temporary placeholder that would be replaced.

@peerwaya
Copy link

@stuartmorgan what's the way forward for bringing texture support to windows?

@stuartmorgan
Copy link
Contributor

@peerwaya I'm not sure what you're asking, but if you have technical questions about how to implement it the right place would be flutter/flutter#38601, not here.

@cloudwebrtc cloudwebrtc deleted the texture_glfw branch July 1, 2020 22:47
@cloudwebrtc cloudwebrtc restored the texture_glfw branch July 1, 2020 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants