 | Steema Issues DatabaseNote: This database is for bugs and wishes only. For technical support help, if you are a customer please visit our online forums;otherwise you can use StackOverflow. Before using this bug-tracker we recommend a look at this document, Steema Bug Fixing Policy. |
Bug 96
| Summary: | Series can't be drawed clearly when setting BufferDisplay property to TRUE | ||
|---|---|---|---|
| Product: | FireMonkey TeeChart | Reporter: | elmec <wave> |
| Component: | Chart | Assignee: | Steema Issue Manager <issuemanager> |
| Status: | RESOLVED NOTABUG | ||
| Severity: | critical | CC: | david, gromov.vsevolod, narcis |
| Priority: | --- | ||
| Version: | 131016 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows | ||
| Chart Series: | --- | Delphi / C++ Builder RAD IDE Version: | |
| Attachments: | BufferDisplay problem at C++ Firemonkey HD Application | ||
I've just tried the test project with our latest sources, and display quality is exactly the same with or without BufferedDisplay, so I guess it was a bug that is already fixed. Just a quick note: Usually in FireMonkey you don't need to set BufferedDisplay=true. In FireMonkey, BufferedDisplay is false by default because FireMonkey itself already implements a double-buffered internal bitmap, so the TChart double-buffer (necessary in VCL), is somewhat redundant. BufferedDisplay=true in FireMonkey is convenient for speed reasons when repainting a form, but as soon *any* TChart or Series property is changed and the chart needs to be recreated, BufferedDisplay=true gives almost no speed advantadge at all. Depending on the FireMonkey canvas class (Direct2D, GDI+, GLES, etc), painting to a double-buffer bitmap can be faster or slower than painting to a normal control handle. However, in XE5 for Android, TChart BufferedDisplay=true makes more sense. The reason is not to avoid "flicker" (like in GDI or GDI+ in VCL Windows), but to avoid FireMonkey Android Canvas to force re-creating the Chart again an again every time something in a form needs to be repainted. Found the cause. There is a bug in FireMonkey that makes this problem. The problem is using TScaledLayout as a parent container for TChart (or for any other control). With TScaledLayout, when resizing the form or maximizing it, FireMonkey does not call the children controls Resize method. So, in this case TChart does not get notified of the resize and the new width by height dimensions, and the final output is "stretched" as it is using the "old" previous dimensions. In the attachment project, if you replace the TScaledLayout (layoutScale variable), with a normal TPanel for example, then everything works fine. We'll keep investigating how to workaround this FireMonkey problem (also happens in XE5), and submit a bug at Embarcadero's Quality Central (qc.embarcadero.com) On second thought, and after reading FireMonkey documentation: http://docwiki.embarcadero.com/Libraries/XE2/en/FMX.Layouts.TScaledLayout I think this is not a bug, its standard FireMonkey behaviour. ScaledLayout works this way, it tells children controls different coordinates than the "real" screen dimensions. |
Created attachment 19 [details] BufferDisplay problem at C++ Firemonkey HD Application I am using Teechart201308XE4 for C++ Firemoneky HD Application. When I set BufferDisplay property to TRUE, the series can't be drawed clearly.