Hi
I'm using TTMSFMXGrid with Felxcel and am starting to experiment with some pretty big spreadsheets. I'd always assumed that the grid would only create visible cells but there's a large memory jump as the RowCount/ColumnCount is increased. E.g. my first pass created a grid on each tab of a TTabControl with 1000000 rows and 16000 columns - to mimic Excel. However that led to 10Mb memory use per grid - too much for large workbooks.
I now just create one grid and re-parent it amongst the tabs. However it is a bit sluggish when switching tabs - not a show-stopper - around half a second delay. Are there any performance improvements in the pipeline or is it FMX limitations that are causing this?
Thanks, Bob
On a related theme, when I drag the mouse to select a multi-cell range the cursor is always ahead of the selection (which eventually catches up). Again, not a show-stopper but it does feel a bit odd. I'm guessing this is an FMX drawing problem?
Cheers, Bob
Hi,
Unfortunately we have already maxed out performance on FireMonkey for the TTMSFMXGrid. Various investigations led to the same result which indicate that FireMonkey is the underlying cause for performance issues. As we adopted the FireMonkey styleability and high customization features we paid the price of less performance, compared to a full "paint-only" implementation. Note that each cell in the grid is an object, as you would place 100 buttons on a panel in VCL instead of painting rectangles in a paintbox. We are not interfering with the cursor so I can only suspect that this is also a FireMonkey issue.
Kind Regards,
Pieter
Hi Pieter
Ok thanks I suspected it was an FMX problem! Hopefully XE7 will bring some performance improvements.
I can get around it if I can get control over the mouse/scrollbar behaviour and using VisibleRowCount, TopRow, LeftCol etc. I'm using the grid in virtual mode so could then just load data into visible cells as required.
However, I'd need an event that I could intercept like "BeforeMouseScroll". This would hopefully also solve the scrolling issues in my other question.
Kind regards, Bob
Hi Pieter
Another quick experiment confirms the performance problem in FMX. I load a large spreadsheet with five sheets and thousands of values in each sheet. At full screen (35 rows and 24 columns) there is a significant delay switching between tabs (I'd say at least half a second). Reducing the visible cells to 3x3 by reducing the app window size makes the delay imperceptable.
Kind regards, Bob
Same behaviour on OSX, not surprisingly, and similar performance. On my large monitor with 40x29 cells visible it takes more than 1 sec to change tabs! Very disappointing, looks like EMB still have some work to do on this.
Cheers, Bob
I might be completely wrong here - did the obvious test of a tab control with 4 grids and it's perfectly usable at all sizes. It looks like it could be something in my data-handling code - will investigate and get back!
Cheers, Bob
No it's not my data handling - seems to be a cumulative effect of re-parenting, assigning OnGetCellData and large values for row and column count. Even with rowcount = 50 and colcount = 30 on OSX it's slow. I'm using Begin/EndUpdate
Cheers, Bob
As we adopted the FireMonkey styleability starting from XE2 / XE3, each cell is an object that is managed by the grid dynamically (re-using cells when scrolling, updating the grid). So there are no more cells allocated than the grid displays. This is unfortunately a performance issue in FireMonkey.
Kind Regards,
Scheldeman Pieter
Hi Pieter
TGrid is, not surprisingly, even poorer in performance. I've raised a QC (124559) using TGrid to illustrate. A TGrid with just 100 rows and 30 columns takes about 1 sec to switch tabs on OSX! Completely unusable.
Cheers, Bob
Hi,
Thank you for your investigation, unfortunately it is even slower on Android / iOS.
Hoping they keep working on performance.
Kind Regards,
Pieter
Hi Pieter
You might be interested to know that my QC report was edited by someone and changed from a B/0 to an S/3 and marked as a Mac OS performance issue! I confirmed the even poorer performance on Android and added a private comment pointing this out.
Cheers, Bob
Hi Robert,
Thank you for your feedback !.
Kind Regards,
Pieter