Cool. Sorry for the late replay, I've been crazy busy recently. I
was wondering if you had any luck getting the decoding straight onto
the directX style bitmap?
*From:*kinovea-dev-bounce@xxxxxxxxxxxxx
[mailto:kinovea-dev-bounce@xxxxxxxxxxxxx] *On Behalf Of *Joan
*Sent:* Wednesday, 16 February 2011 6:25 PM
*To:* kinovea-dev@xxxxxxxxxxxxx
*Subject:* [kinovea-dev] Re: Direct2D
Just a quick note to say that I'll try to focus on the Direct2D
rendering stuff for a while.
Hopefully, to get some sort of a working base that we can build upon
and refactor later...
joan.
Le 14/01/2011 23:42, Hugh a écrit :
I'm in a rush, so just quickly:
As long as there is a sound way to destroy it and any threads it may
create, then all is good! I just came from outside C# so not so use
to it all.
The DrawVideoBitmap() was very much a hack to try and get it to work
in the current program. It would be good if it can draw straight onto
a DirectX style object, and do all rendering on it (there are many
functions for it). Obviously the more it is in the hardware (and not
just copied over), the best results will occur.
I don't know enough about FFMPEG to know if it is possible to draw
from it onto these surfaces, but I'm sure it must be since VLC is very
quick at rendering.
The whole class was designed to have a module feel to it, but also to
fit into the current program. I did something close to what you have
to do the rendering, but I hope the class can easily be changed to fit
any new designs. As I did more work on it, I realised there were
other bottle necks in the program that would need to be fixed get it
fully working (like drawing onto DirectX objects, new rendering
process etc).
I left the other classes (like DirectX 9 and 10) mainly because
Windows XP does not support Direct2D. However I guess there is a time
people must decide to move on. They would be much harder to work with
as you must draw the shapes in the perspective, not simply simple
objects. Direct2D also has many other small advantages like for
remote desktop, integration etc. I never tested them, but didn't want
to remove the options in case someone wanted to go down this path in
the future. Personally I favour Direct2D the most.
At the moment I am rather limited for time (sorry!), but this is
something I would love to see in the program.
Hugh
*From:*kinovea-dev-bounce@xxxxxxxxxxxxx
<mailto:kinovea-dev-bounce@xxxxxxxxxxxxx>
[mailto:kinovea-dev-bounce@xxxxxxxxxxxxx] *On Behalf Of *Joan
*Sent:* Thursday, 13 January 2011 10:19 PM
*To:* kinovea-dev@xxxxxxxxxxxxx <mailto:kinovea-dev@xxxxxxxxxxxxx>
*Subject:* [kinovea-dev] Re: Direct2D
Hi,
I have tried the Direct2D / SlimDX code you sent.
I wasn't too sure as to how exactly use the control, here is what I did:
- Added a Direct2DControl member to PlayerScreenUserInterface.
- In the PlayerScreenUserInterface constructor I call
Direct2DControl.SetControl() passing in the center panel (to test on
the back panel for now)
- immediately call Direct2DControl.Run() to trigger initializations.
- At each new frame, (in PlayerScreenUserInterface.ShowNextFrame), I
call Direct2DControl.DrawVideoBitmap() passing in the decoded image,
- and Direct2DControl.Update() to actually draw on the panel.
Let me know if I did anything wrong. Did you also modify
PlayerScreenUserInterface in this way for your tests ?
It seems to work pretty well.
I've tried to instrument and get some figures regarding speed, but it
proved harder than I thought to really pinpoint the rendering time.
(Also I've recently changed machine and it's like everything is
running super fast :-))
The part taking the most time (about 10 to 20ms each frame on my
machine) would seem to be DrawVideoBitmap().
This function involves copying the whole GDI+ bitmap into a Direct2D
bitmap for later use. This is a step we can probably avoid completely
by decoding directly into a Direct2D bitmap from the FFMpeg code.
This is maybe what you suggested in the forum thread... In the case of
pre-extraction to memory, we can also probably keep an in-memory array
of Direct2D bitmaps instead of an array of GDI+ bitmaps. I'm sure
we'll find a way to avoid this extra copy.
About your concern to release resources, I don't think we need to use
a separate form for rendering and react to the OnClose() event of it.
Screens must implement a BeforeClose() method (see AbstractScreen)
which is triggered when the screen is closed (close button, changing
screens configuration, etc.)
We should be able to use it to ask the PlayerScreen and the renderer
to dispose any outstanding resources.
We'll probably need to transform and simplify the DirectXInterface class.
Also, I don't know if we need the other classes, (Direct3D10Context,
etc.) ? If not, we might even merge the two for simplicity.
I haven't looked at the direct2D drawing primitives and how we might
implement the drawing tools visuals.
The architecture discussion will probably depend on how these can be
abstracted between Direct2D and GDI+.
I will create a topic on the wiki to push some schematics of possible
architectures so we are clearer about what we discuss.
Let me know of your experiments.
Thanks,
joan.
Le 10/01/2011 21:34, Joan a écrit :
Hi!
I am super sorry for the delay.
Unfortunately, I haven't had much time to look into this, but I will.
(I have some issues at work with the company wanting to close the
local office, this has somewhat prevented proper focus on the project,
but it's going to resolve one way or the other in the next few weeks.)
Thanks
joan.
Le 05/01/2011 17:34, Hugh a écrit :
Hey Jean,
Was just wondering how the Direct2D code was working for you? Did you
have any luck moving the drawing onto a new form? Just didn't see any
recent changes in the code and was hoping it is working!
Thanks,
Hugh
