Skip to content

WPF drawing with constant fps #5725

@vsfeedback

Description

@vsfeedback

This issue has been moved from a ticket on Developer Community.


[severity:Other]
Hi,

we have a mixed .net 4.8 forms and WPF application, that mainly shows live video.
Currently we use forms with native DirectX11 to render the video.
Now we would like to do rendering with „native“ WPF for a nicer integration into the rest of the application.
We use the D3DImage todo so.
With the forms implementation we can achieve up to 50 video streams with each 30fps (source resolution is 704x576).
After doing lots of optimizations, the WPF implementation also works fine, but with a raising number of video streams, the WPF framerate starts decreasing very early although CPU and GPU (never above 10%) are fare away from being overloaded.

Streams,CPU load, WPF fps
1 10% 60
9 26% 56
10 27% 33 <
19 42% 28
21 44% 25 <
25 49% 20
31 56% 20
35 60% 17
43 69% 16
50 77% 12

There is a noticeable behaviour, the fps keep stable for a longer time and then suddenly drops in steps (60, 30, 25, 20, 15, 12, 9).

The WPF implementation works as follows:
We just use one D3DImage and all video stream are rendered into own regions of one attached DirectX11 texture (using several deferred context). So only one update (Lock, AddDirtyRect, Unlock) of the D3Dimage has to be done from GUI thread. The different video streams are then „drawn“ with an ImageBrush into different parts of the UI. The actual DirectX rendering, decoding and so on is done in their own threads.

The D3DImage update needs about 1 to 3ms per call. We tried doing the update within the CompositionTarget.Render event or dispatching it into GUI thread with a fixed interval (33ms), but it doesn‘t change the behaviour very much.

We used the „WPF Performance Tools“ to verify framerate and hardware rendering.

Question:
What can we do to get a more stable and higher framerate for the WPF rendering (for sure as long the system isn‘t obviously overloaded).
Are there any settings (registry, properties, app config, …) to influence this framerate algorithm of WPF?
What influences this algorithm?
Is the CPU or GPU load measure?
Is the GUI or WPF rendering thread(s) measured?

Thank for your help in advance,
Oliver


Original Comments

Feedback Bot on 11/18/2021, 06:10 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.


Original Solutions

(no solutions)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions