Allow getting the raw texture from mvRawTexture #1134
Replies: 15 comments 3 replies
-
Hi,
It depends on the intent. We designed the mvRawTexture & mvDynamicTexture to be used when the texture needs to be updated often (i.e. every frame). We optimize for this differently per platform and in the case you are referring to, we use pixel buffer objects. I believe this is considered "best practice" for frequently updated textures. Allocating memory on the GPU is expensive, so you really want to minimize how often you do that. In 0.6, for dynamic textures, we reallocated every frame and it was extremely slow (100x slower in fact). If you only need to update occasionally, it's recommended to use mvStaticTexture which is created without CPU access flags. When you need to update it, just recreate it.
Again, if you are not planning on updating often, why not use a mvStaticTexture?
We do plan on adding this ability in the future however we have to decide on a consistent API for doing so across platforms. Its pretty straight forward for OpenGL where the "texture" is just an unsigned int handle but not for the other platforms. In windows, you need a pointer to a shader resource view, and on MacOs you need a MTLTexture and the texture descriptor I believe.
That is actually how mvRawTexture is meant to be used (look at wiki page).
I apologize about the internal documentation (mvPythonParser included) lacking! The backend is starting to settle down, so we are spending alot more time cleaning up and documenting. We'd like to help contributors get around.
I'd have to see how you did it but I'm sure we can help! You can show some of the code here contributing or if you are in the discord server, let use know your username and we can send you an invite to the contributor channel! |
Beta Was this translation helpful? Give feedback.
-
Thanks for the detailed response @hoffstadt ! My username is the same on Discord :) What I did -> https://github.com/ProfFan/DearPyGui/pull/2/files Strangely |
Beta Was this translation helpful? Give feedback.
-
Just left a comment on the PR. Let me know if that works. |
Beta Was this translation helpful? Give feedback.
-
@hoffstadt You suggestion works! I think I can try put up a demo now. Will post when I finish... |
Beta Was this translation helpful? Give feedback.
-
Awesome! |
Beta Was this translation helpful? Give feedback.
-
I have a working demo using the fork:
|
Beta Was this translation helpful? Give feedback.
-
This is very very dirty, but it works. Need to think about the API now. |
Beta Was this translation helpful? Give feedback.
-
Code is in https://github.com/ProfFan/DPG_Demo . Aiming to integrate with vispy now. |
Beta Was this translation helpful? Give feedback.
-
I have a demo working using I think the way I patched DearPyGui is not the best solution, but it works nicely. Still, event processing is a problem with |
Beta Was this translation helpful? Give feedback.
-
This is awesome. Glad you are making some progress. I'm hoping we will follow suit sooner rather than later. |
Beta Was this translation helpful? Give feedback.
-
@hoffstadt Glad to hear that! What do you think about adding a new widget in DPG that is conditionally compiled (on Linux + GLFW), which can pass event to the underlying renderer and renders a raw texture? I think this will enable a lot of cool applications before the new 3D engine is ready. Also, we can later add more platforms to support matrix by similar approach to |
Beta Was this translation helpful? Give feedback.
-
I'm not opposed to it at all. We just need to come up with a good and scalable API for it. Converting this issue to a discussion. |
Beta Was this translation helpful? Give feedback.
-
My vision for the API is:
I can make a prototype in my fork, and we can evaluate it together. For OpenGL, it's simple because the texture is just a |
Beta Was this translation helpful? Give feedback.
-
+1 feature, this would also allow some primitive video playback under DPG since writing raw video frame textures from cv2 to ModernGL is quite doable from my experience. (or from some external video decoding raw FBO) For a first iteration of this API I'm ok with just this proposed We don't want to add complexity here for the "scalable" part, so keeping MGL and DPG separate, achieving "keep coding in mgl" but with DPG integration would be the mindset? Like how moderngl hugs imgui with their |
Beta Was this translation helpful? Give feedback.
-
100% behind the idea of a 3D Widget; not 100% behind the idea of using raw OGL commands in the API, which means the same amount of time designing it proper still exists and is required. All the things you mentioned about extending the API with this, are things already on the roadmap. I would seriously hope not much effort is thrown into this beyond just slapping in a widget (for now). |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
Currently, the mvRawTexture item will always fetch the texture from a memory location upon updating. However, when used with 3D contents, it's more efficient to just bind to a texture on GPU instead of refilling from RAM.
Describe the solution you'd like
Either an option in mvRawTexture that disables the fetching or a new texture item that allows getting the native (i.e. GLFW) texture so we can draw scenes on it.
Describe alternatives you've considered
We can always render to a CPU array and ask mvRawTexture to fetch from it.
Additional context
I tried to implement this myself but the documentation on the mvPythonParser is really lacking. I managed to add a function that extracts the
_texture
as anint
, but adding another function that disables the update does not work, and I don't know why.The error is like:
but code is exactly the same like the one getting the texture id (which works). Debugged for 4hrs, no avail.
Beta Was this translation helpful? Give feedback.
All reactions