[TTMSFNCPlanner][FMX] Slow respones when using HTML as item text.

FNC TMS FNC UI Pack
1

We have per day about 120item in the planner (vertical, 1day view, multi columns, 20 colums, about 6-10 appointments per column).

We just found out that the application becomes quite unusable when we are using HTML for the item text.
Dragging items, or resizing items becomes very slow till not possible.
We also see for example (about) a 1 second delay when selecting an item. This delay is not there is we use plain text as text.
got some better result with
planUI.AntiAliasing := False;
planUI.OptimizedHTMLDrawing := False;
planUI.NativeCanvas := True;

the following line renders the planner empty ? items are not drawn?
planUI.ItemCachingMode := picmFullCaching;

2

Hi,

There seems to be an issue with picmFullCaching. We have applied a fix. The next version of the TMS FNC UI Pack will address this. setting it to picmFullCaching will improve the reponsiveness when applying HTML text. Please note though that HMTL text is very resource intensive and this is the cause for the slowness when having multiple items.

3

Yes, but very strang, we also have an application which still uses the normal FMXPlanner, and this one does not have that issue. But for now, i just make some simple text templates till the issue is fixed. (we use template parser to generate the htlml/text content, so no problem there).
thnx for the quick response!

4

That's strange indeed. That must be something inside the HTML engine then. Can you post us a sample of HTML text that you are using?

5

Here is an template were using, the <%{name}%> things are normally parsed and will be text.

<body  bgcolor="<%HTMLColor%>">
<font face="calibri" size="15">
<img src="idx:<%IconIndex%>" height="32" width="32"><font size="24"><%AfspraakSoort%>
<font size="15">
<hr>
<p>
Geplanned: <b><%fmtdt('hh:nn', DisplayStart)%>-<%fmtdt('hh:nn', DisplayEnd)%></b>   Gewenst: <b><%VoorkeurBlok%></b>
</p>
<hr>
<p>
<%Storingsbon.voorletters%> <%Storingsbon.naam%><br>
<%AdrStraat%> <%AdrHuisnr%><br>
<%AdrPostcode%>  <%AdrPlaats%> (<%AdrLandcode%>)<br>
(Lat/Long: <%fmt('%7.4f', AdrLatitude)%> / <%fmt('%6.4f', AdrLongitude)%>)
</p>
<hr>
<p>
<b><% Storingsbon.toesteltypeomschrijvingnl%></b><br>
<% wordwrap(Storingsbon.meldingklant_asstring, 120, '<br>')%><br>
Volgend PO: <% fmtdt('dd-mm-yyyy', Storingsbon.datumvolgendonderhoud)%>
</p>
<hr>
<p>
<p style="font-size:10px"><font face="calibri" size="12">
Gemeld: <% fmtdt('dd-mm-yyyy hh:nn', Storingsbon.datummelding)%><br>
Aangemaakt: <% fmtdt('dd-mm-yyyy hh:nn', Storingsbon.aanmaakdatum)%><br>
Laatst gewijzigd: <% fmtdt('dd-mm-yyyy hh:nn', Storingsbon.laatstewijziging)%>
</p>
<hr>
<p style="font-size:10px"><font face="calibri" size="10">
PlanAppointment: <%pkvalue%>, ObjectType: <%ObjectType%>/<%ObjectSubType%>, ObjectID <%ObjectID%>, OnderhoudPlanning : <% storingsbon.pkvalue%>, Bewoner : <% storingsbon.bewoneridno%>, Contract : <% storingsbon.contractidno%>, Toestel : <%storingsbon.toestelidno%>
</p>
</body>
6

I replaced the HTML with normal text templates, and as soon as items get a little more lines say (5 till 15 lines of text per item) then we notice the slowing of the response. Besided the slowing of the resposne the dragging/sizing becomes impossible to work. Tested it with AutoFit items on and off.

Really notice a big difference in selecting items to, noticing a delay when the item is selected after clicking on it.

So it seems the problem has somewhat todo with multiline content of the items.

7

ignore the multiline remark, i still had some html cached in the server which generates the data for the client. (the server gets the content from a template parser service, which parses the html/text templates for objects).
So with normal text, it works good now.

8

Thanks for the additional feedback!

9

i did a run, with prodelphi, see the image of the result attached, i think the InternalCalculateText gets a little to often called. (quick view).
(attaches as image and prodelphi .hst file, (remove .txt from the .hst filename)

Planner4FMXClient.hst.txt (17.1 KB)
)

FNCPLANNER_PRO_DELPHI
FNCPLANNER_PRO_DELPHI2464×1000 240 KB

Processing: Planner4FMXClient.hst...

10

This is because of anchor detection in the mousemove (XYToItemAnchor). Can you see what happens when you add an Exit in that function?

11

That certainly makes a difference. The "click and select" still has a delay, but the Exit improves the moving and sizing of items noticable!.

12

But performance drops as soon as i change back to full html templates.
I see this line often, in a couple routines, the UpperCase maybe causing delays also?

if ASupportHTML and ((Pos('</', AText) > 0) or (Pos('/>', AText)  > 0) or (Pos('<BR>', UpperCase(AText)) > 0))

(i think storing it with the item with setting the Item.Text string and then informing the procedure/functions whether to use html or nor would perform better, instead of doing this check on a numerous places):

13

The next release is planned for next week. The caching issue should then be fixed and allow you to navigate and interact with the items quicker. If something comes up after the fix, please let us know.

14

ok, we'll do, thnx for the response !

1 Like
15

Still have some speed problems, with the FNCPlanner, it seems the FMX/VCL planners are faster in rendering? (do you have comparison data for this)?

16

HTML is typically slow, for FNC, FMX & VCL as well. The speed depends on the amount of text and the formatting. We don't have any comparison. Note that the VCL planner also is completely different than FNC, so not comparable

17

tried it with empty item.text, still is slow
(vertical 20 resources, around 70 items total, dayview)

18

tried with save items to json, then load items in test project (just fncplanner component), speed is good.
problem is in the combination in my app. i go hunting :slight_smile:

19

Did you use TMSFNCPlanner1.BeginUpdate & TMSFNCPlanner1.EndUpdate around the loading code?

20

yes, that was was there al the time already.
It's something strange in my project, i got the loadfromjson with fast painting now. its somekind of combination what causes the delay somehow. a big puzzle.