Description
Hello,
I hope this message finds you well.
I'm a support engineer from DevExpress. We recently received a report from a customer (T1326748) who noticed that the unmanaged memory consumed by a WPF application with our controls on a machine with an AMD GPU/CPU is significantly greater than on machines with Intel.
We thoroughly researched this behavior on our side, and it occurred that the issue is not specific to our controls - it occurs in any WPF application that utilizes many elements whose ClipToBounds property is set to True.
We created a simple project (dxSample.zip) that you can use to reproduce this problematic behavior. Please compare the amount of unmanaged memory consumed by the application with True and False in the ClipToBounds property defined at the level of UI elements (Border and TextBlock). We used dotMemory to analyze the consumed memory in our tests.
Reproduction Steps
- Run the attached project (dxSample.zip).
- Attach a memory profiler to the process.
- Scroll the main window's content vertically and horizontally multiple times.
- Maximize the window and repeat step 3.
- Restore the window state and repeat step 3 again.
- Research the memory consumed by the application.
Expected behavior
Similar to how it works on machines with Intel. Or, at least, how it works with ClipToBounds=False:
| GPU |
ClipToBounds |
Result |
| Intel |
True |
 |
| Intel |
False |
 |
| AMD |
False |
 |
Actual behavior
| GPU |
ClipToBounds |
Result |
| AMD |
True |
 |
Regression?
No response
Known Workarounds
No response
Impact
We use the ClipToBounds option rather widely, and the large memory consumption can affect a really significant number of our customers. Therefore, we will really appreciate it if you can research this problematic behavior on your side and check if there are ways to optimize this behavior.
Configuration
In our tests, we used a machine with the following environment:
.NET 10
CPU - AMD Ryzen 9 PRO 7940HS w/ Radeon 780M Graphics - 8 Cores
RAM - 32 GB
APU - AMD Radeon(TM) Graphics - Primary/Integrated
VRAM - 512 MB - DDR5 2800 MHz
Driver Version - 26.10.07.05-260506a-200691C-AMD-Software-Adrenalin-Edition
AMD Windows Driver Version - 32.0.31007.5012
Direct3D API Version - 12.2
Vulkan™ API Version - 1.4.344
OpenCL™ API Version - 2.0
OpenGL® API Version - 4.6
Direct3D® Driver Version - 9.17.11.0287
Vulkan™ Driver Version - 2.0.388
OpenCL® Driver Version - 32.0.31007.5012
OpenGL® Driver Version - 32.0.31007.5012
2D Driver Version - 8.1.1.1634
2D Driver File Path - /REGISTRY/MACHINE/SYSTEM/CurrentControlSet/Control/Class/{4d36e968-e325-11ce-bfc1-08002be10318}/0000
UI Version - 2026.0506.2249.2099
AMD Audio Driver Version - 10.0.1.38
Driver Provider - Advanced Micro Devices, Inc.
Windows Edition - Windows 11 Professional (64 bit)
Windows Version - 24H2
Should you need any additional information from our side, please just let me know.
Regards,
Andrey
Description
Hello,
I hope this message finds you well.
I'm a support engineer from DevExpress. We recently received a report from a customer (T1326748) who noticed that the unmanaged memory consumed by a WPF application with our controls on a machine with an AMD GPU/CPU is significantly greater than on machines with Intel.
We thoroughly researched this behavior on our side, and it occurred that the issue is not specific to our controls - it occurs in any WPF application that utilizes many elements whose
ClipToBoundsproperty is set toTrue.We created a simple project (dxSample.zip) that you can use to reproduce this problematic behavior. Please compare the amount of unmanaged memory consumed by the application with True and False in the ClipToBounds property defined at the level of UI elements (Border and TextBlock). We used dotMemory to analyze the consumed memory in our tests.
Reproduction Steps
Expected behavior
Similar to how it works on machines with Intel. Or, at least, how it works with ClipToBounds=False:
Actual behavior
Regression?
No response
Known Workarounds
No response
Impact
We use the ClipToBounds option rather widely, and the large memory consumption can affect a really significant number of our customers. Therefore, we will really appreciate it if you can research this problematic behavior on your side and check if there are ways to optimize this behavior.
Configuration
In our tests, we used a machine with the following environment:
Should you need any additional information from our side, please just let me know.
Regards,
Andrey