Các vấn đề về hiệu năng chạy các ứng dụng WPF/Win32 cạnh nhau?

Question

Chúng tôi có một phiên bản cũ (Win32) và mới (WPF) của phần mềm blotter của chúng tôi, mà các nhà giao dịch hiện đang chạy cạnh nhau. Tuy nhiên, việc chạy ứng dụng WPF thường làm chậm tốc độ vẽ lại của ứng dụng Win32.

Nếu không có ứng dụng WPF đang chạy (hoặc thu nhỏ), tốc độ vẽ sẽ linh hoạt và nhanh chóng trong ứng dụng Win32. Với ứng dụng WPF mở cùng với nó, tỷ lệ vẽ giao diện người dùng của Win32 appl chậm lại đáng chú ý. Chạy ứng dụng WPF dường như kích hoạt việc sử dụng một số tài nguyên được lấy ra khỏi ứng dụng Win32 (cả đồ họa nặng) - làm chậm tốc độ của nó.

CPU và bộ nhớ không ở bất kỳ nơi nào gần bão hòa, vì vậy nó dường như không liên quan đến chúng. Giảm độ phân giải và/hoặc giảm số lượng màn hình để hiển thị trên (do đó giảm mức sử dụng bộ nhớ thẻ video và tải băng thông) không có sự khác biệt đáng chú ý, do đó nó dường như không phải là vấn đề hiệu năng đồ họa phần cứng.

Một giả thuyết cho rằng có thể giải thích nguyên nhân là như sau:

Dưới mui xe, chúng ta biết rằng cả WPF và Win32 thông tin đồ họa ứng dụng đầu ra vào một cửa sổ "Thông điệp bơm" mà về cơ bản là một danh sách các hướng dẫn của những gì để vẽ lên màn hình. Có vẻ như khi ứng dụng WPF không hoạt động, Win32 có quyền truy cập đầy đủ vào bản cập nhật này và màn hình là chất lỏng. Chạy ứng dụng WPF cùng với nó đặt thêm thông điệp vào hàng đợi này, vì vậy ứng dụng Win32 phải cạnh tranh khó khăn hơn để truy cập vào nó (để cập nhật từng phần tử màn hình), do đó "làm tắc nghẽn bơm" cho hiệu ứng chúng ta thấy.

Nếu trường hợp trên xảy ra, bất kỳ ai có thể đề xuất phương pháp tiếp cận để quản lý/kiểm soát bơm thông báo cửa sổ để ngăn điều này xảy ra không?

Nhấp nháy là loại bạn thường nhận được khi tài nguyên yếu, nơi bạn có thể thấy các yếu tố riêng lẻ (biểu mẫu, nhãn) nhấp nháy và dần dần vẽ lên màn hình.

Nếu có bất kỳ đề xuất/ý tưởng nào, hãy cho chúng tôi biết.

Answer 1

Mỗi quy trình sẽ có máy bơm tin nhắn riêng - điều này không được chia sẻ.

Nếu bạn không thấy mức sử dụng CPU cao, thì WPF đang sử dụng hiển thị phần cứng, vì vậy nó có thể là độ bão hòa GPU. Bạn có thể lấy thông tin về việc sử dụng GPU không?

Các phương pháp bài chi tiết sau đây của việc sử dụng GPU:

Programmatically fetch GPU utilization

Answer 2

Được rồi, tôi nghĩ rằng chúng tôi đã tìm ra nguyên nhân, và sửa chữa. Tóm lại, phần cứng và phần mềm tăng tốc cửa sổ không chơi tốt đẹp. Sử dụng phần mềm hiển thị trên bảng sửa lỗi ổn định mà trước đây đã có khi chạy các cửa sổ tăng tốc phần cứng. Vì ứng dụng Win32 cũ của chúng tôi sẽ ngừng hoạt động sớm, đây là một sự bắt buộc khả thi - chúng tôi chỉ có thể chuyển đổi tăng tốc phần cứng trở lại khi chúng tôi xóa ứng dụng cũ.

Ghi chú dưới đây:

Nó có vẻ như vấn đề này đã được gây ra bằng cách chạy một phần mềm tăng tốc 2D ứng dụng truyền thống (X) và tăng tốc phần cứng 3D WPF một (Y) cùng một lúc, và là một đồ họa vấn đề trình điều khiển.

Buộc Y chạy trong chế độ tăng tốc phần mềm WPF cũng gây ra ít sự xuống cấp trong hiệu suất cuộn (vì nút cổ chai vẫn là mã bố cục nội bộ của lưới). Tuy nhiên, những gì nó làm là loại bỏ vấn đề bản vẽ chậm trong X, vì Y hiện đang chạy như một ứng dụng 2D tăng tốc phần mềm, giống như tất cả các ứng dụng Windows khác trên các máy của nhà giao dịch. Điều này giải thích tại sao không ứng dụng nào khác ngoài Y gây ra sự chậm lại - có vẻ như ứng dụng đồ họa phần mềm và phần cứng tăng tốc không chơi tốt khi chạy cùng một lúc. Điều này có ý nghĩa - khi tôi chơi một trò chơi tăng tốc phần cứng, ví dụ, tôi đã nhìn thấy tương tự (nơi máy tính để bàn vẽ lại rất chậm khi chuyển sang/từ trò chơi giữa chế độ tăng tốc phần cứng/phần mềm).

Rất may, chúng tôi có thể tắt hiển thị phần cứng mà không ảnh hưởng nhiều đến hiệu suất. Khi X ngừng hoạt động, chúng tôi có thể chuyển đổi tăng tốc phần cứng trở lại cho các lợi ích nhỏ mà nó cung cấp trong Y (hỗ trợ các hoạt ảnh mượt mà hơn và sử dụng nhiều hơn các gradient tô màu mà không làm chậm vv).