Forum > Cocoa

[Solved] Demo to benchmark TextOut on win64/gtk2/Cocoa - Cocoa is very slow

<< < (2/5) > >>

AlexTP:
Ops, corrected my test, I compared with too old app version.

Martin_fr:
Having noted this here due to the mail list.... Now I am not the expert on Cocoa, I can't give any specifics to it.
So this post of mine may end up a one-off contribution to this thread.

What I do know is that indeed "CharsDelta" is a feature from Windows.

It is mainly used to force chars into a monospaced grid. Though in theory every cell (for each char) can have it's very own width.
It basically forces each char to be adapted to a given width.

And it appears that is a Windows only thing. And other WS have various "workaround implementations". Usually those are slow.
And may have other Side effects, such as script fonts (Arabic) not looking correct at all, because the text may be drawn one char at a time....

==> Therefore it is probably correct to split textout and other routines into with/without CharsDelta.


As to how this is best achieved on any WS, well I do not have that answer.

One avenue possible worth exploring is, if this was implemented in the original Cocoa or later added.
Afaik in gtk2 it was latter added. But cocoa is a younger WS, and it may have been done from the start.

Anyway, one might get lucky exploring this code with "git blame". Maybe there is an older and faster version.

Zoë:

--- Quote from: Martin_fr on September 29, 2021, 09:54:15 pm ---What I do know is that indeed "CharsDelta" is a feature from Windows.
...
Therefore it is probably correct to split textout and other routines into with/without CharsDelta.
--- End quote ---

I agree that the simple case should be an optimized path if it isn't already, but also, the CharsDelta support is not the only overhead, and may not even be the most significant factor.

Aside from the TCanvas.TextOut calls, none of the timings I gave use the LCL GDI routines for drawing at all, and don't attempt to emulate CharsDelta, but still have unexpected slowdowns.  Using simple, raw Cocoa calls to just draw strings with a particular font/foreground/background color shows that having that routine fill the background color is significantly slower than measuring the string, manually filling the background rect, then drawing the foreground text on top.  That doesn't make any sense.  Changing the foreground color of the existing string object similarly takes longer than it should.  Based on my understanding of how the macOS text rendering systems work, that shouldn't be the case

AlexTP:

--- Quote ---I agree that the simple case should be an optimized path if it isn't already, but also, the CharsDelta support is not the only overhead, and may not even be the most significant factor.
--- End quote ---

Even if CharsDelta is not the most significant factor, let's apply the current Zoe's patch? It speeds up things, and I will be 'safe' if I forgot to apply the patch (using Lazarus latest).
Dmitry, if you agree, pls apply in your fork?
Later people will improve things.

Zoë:
David is working on a proper fix for this issue.  We've had some issues crop up with macOS 12 that are taking priority right now, but we should have a full patch relatively soon.  My patch breaks support for underline and strikethrough styles and I still do not support applying it as-is.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version