Since the introduction of Direct2D(D2D)/DirectWrite with Xojo 2016r4 I have been noticing a gradual decline in the performance of UI elements. With the implementation of the latest windows framework I decided to do a little testing so I spent this afternoon tweaking my test routines and gathering some data.
The default window layout has an oval painted to the background of the window and 14 controls, the control numbers shown on the chart are the number of additional labels placed onto the window. I also did a test making those additional labels transparent as well as other tests removing the paint from the window (physically deleting the Paint event). I then did a similar test with a new C# .Net project using Windows Forms to compare things. The 100 control test has about 50 controls on the window and 50 off it, this was done to check that culling was working correctly. Each test was repeated 5 times and averaged to account for system spikes.
Hardware acceleration was one of the factors being touted with the introduction of D2D but all it seems to have done is slowed things down, could this be looked into?
Notable findings:
- 2016r3 (GDI) follows the same pattern as a modern C# .Net app.
- A large performance hit when moving from 2016r3 (GDI) to 2016r4.1 (D2D)
- A marginal performance hit after the implementation of the new windows framework in 2018r1
- A large performance hit when using transparent controls in 2018r1 (D2D with new windows framework)
- With just 30 (14+20) controls you’re almost at the minimum speed of your window, 20FPS with my hardware.
- The flat line from 30-100 controls in 2016r4.1 and onwards could indicate a bottleneck that needs addressing.
This is the forum version of <https://xojo.com/issue/52217> so we can discuss things without the ticket being forgotten about but if you have some pertinent information for the ticket please do add it into the feedback system.