Forum > Cocoa

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

<< < (3/5) > >>

skalogryz:

--- Quote from: Zoë on January 14, 2022, 10:04:42 pm ---We've had some issues crop up with macOS 12
--- End quote ---
anything for LCL to be concerned about?

Zoë:

--- Quote from: skalogryz on January 14, 2022, 10:10:11 pm ---anything for LCL to be concerned about?
--- End quote ---

No. 

We use the ScrollWindowEx API pretty extensively for our internal editor/grid/treeview controls.  LCLCOCOA's implementation just invalidates the entire control rather than using a bitblit like Win32/Qt do, so it's a lot slower.  We had an alternate implementation that used NSView.scrollRect_by instead, but Apple changed that in 10.14 to do a full invalidate too, so it's no longer any better.  We worked around that by having a new TCustomControl subclass that uses double buffering and System.Move to scroll the contents.  Unfortunately, to avoid conversion overhead, the backing bitmap and context have to exactly match what macOS is using for the view's drawing surface, and that's been very fragile.  Long term we're now planning on making our custom controls use NSScrollView natively instead to avoid fighting Apple, but in the meantime we've had to work around breaks/crashes whenever macOS or Xcode get updated.

Zoë:

--- Quote from: skalogryz on January 14, 2022, 10:10:11 pm ---anything for LCL to be concerned about?
--- End quote ---

Oh, there was one thing:  We needed to make some changes to NSTableView related to the new "style" property they introduced, which added a bunch of padding to listboxes.  The one I know of is calling NSTableView.setStyle(NSTableViewStyleFullWidth) in TCocoaTableListView.initWithFrame.  I think that was Xcode and/or MACOSX_DEPLOYMENT_TARGET dependent. 

It looks like we have quite a few changes to  CocoaTables.pas though, and I think we use it in a non-standard configuration (I see DYNAMIC_NSTABLEVIEW_BASE defined), so I don't know how much affects stock LCL.  I'll have David look into contributing the relevant changes upstream after he gets the TextOut patch finalized.

skalogryz:

--- Quote from: Zoë on January 15, 2022, 12:06:12 am ---It looks like we have quite a few changes to  CocoaTables.pas though, and I think we use it in a non-standard configuration (I see DYNAMIC_NSTABLEVIEW_BASE defined), so I don't know how much affects stock LCL.  I'll have David look into contributing the relevant changes upstream after he gets the TextOut patch finalized.

--- End quote ---
Apple has not remove NSCell APIs yet (and not much deprecation is happening there).
I think for now NSCell has more features implemented, but I'm all for removal NSCell based implementation at some point.


--- Quote from: Zoë on January 15, 2022, 12:06:12 am ---We needed to make some changes to NSTableView related to the new "style" property they introduced

--- End quote ---
ah yes. Now I recall that TListView looks a bit weird on macOS 12.
thanks for the highlight!

Zoë:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39641

Polished patch finally submitted.  :D  David doesn't monitor the forums, so any feedback related to it should happen in the bug tracker.

One thing to note: TCanvas.TextOut calls both ExtUTF8Out and TextWidth, which adds about 30% overhead relative to calling just ExtUTF8Out on its own.  There doesn't appear to be a way to eliminate that in a way that would satisfy the existing design constraints without optimizing for this specific edge case.  It's already significantly faster, but if you need a bit of extra speed just use ExtUTF8Out directly instead.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version