Einzelnen Beitrag anzeigen

Kas Ob.

Registriert seit: 3. Sep 2023
347 Beiträge
 
#3

AW: Desaströse Performance von TRichedit

  Alt 11. Sep 2024, 16:28
Hi,

TRichView is very specific class, is not one of the usual Windows basic classes, yet it is encapsulated as one, it comes with own COM connection and interfaces even if you didn't ask for them,

However, there is few versions and they differ a little bit, you can get better knowledge of what version you can use from here:
https://learn.microsoft.com/en-us/wi...-edit-controls

Now to what i think is happening with your case, and as i don't have any newer than XE8, so my thoughts here are more general and very wide, so sorry if i didn't hit anything helpful:
1) XE8 do use RICHEDIT20W , this is version 2.0 and somehow it is fast enough very close to Windows WordPad, so it will be nice to share with us the difference between the versions you witnessed the performance degradation.
2) The problem with such classes are messages, the more you introduce the more functionality you can have, yet some of these message will affect the performance greatly as they will be used by the OS in very callback style on each line !! this will as you called it will be catastrophic performance drain, to explain this more, imagine you have a TListView with mixed design, wrongly performing like virtual and non virtual, in this case for each line you add there will a message handle even you already sent the caption and items and ...etc, yet messages will be delivered and must answered, again in wrongly mixed design these message will answered with nothing by the default handler and yet visually it will be alright but the speed will suffer greatly, this might be happening with RichView classes, specially if there is custom background handling.

In all cases,
1) try to find the class (version) you see performance degradation.
2) If you can access the sources then compare and share with us what messages implemented for the old and the new one, the procedures will looks like this
procedure XXXXX(var Message: TMessage); message YYYYY; .


In case these helps and shows something useful, then you have to strip the code and remove the messages and most likely will see a great deal of performance boosting, of course you will loose some functionality, but if you do not care about stuff like bidiMode which of course can't affect the speed, but others like WM_PAINT and its sisters.

Hope that helps.
Kas
  Mit Zitat antworten Zitat