Re: [MACTCL] Major update to the macOS port of Tk

[Marc C. <mar...@gm...>]

I think you are proposing to implement every widget as a subview of the
contentView, since a CALayer can only be attached to an NSView.  Apple says
in their documentation that performance is bad if a contentView has too
many subviews.  Tk windows can contain a huge number of widgets, especially
when an extension like tablelist is used.  So using a subview for every
widget is a bad idea.  (Feel free to try it, if you think Apple is wrong.)

On the other hand, one would not expect to have huge numbers of OpenGL or
Metal widgets in a window.  Such a widget could be implemented as a subview
which is managed by a Tk widget.  That is what is done it Togl and TkGL.

- Marc



On Thu, Jul 4, 2024 at 3:39 AM Uwe Kirschner <Uwe...@gm...> wrote:

> Hello Marc,
> why not have one CALayer per widget?
>
> That way one could easily implement OpenGL and Metal widgets
> (CAOpenGLLayer, and CAMetalLayer)
>
> In the one CALayer-per-toplevel scenario an OpenGL or Metal widget would
> need to first render to texture, then copy the texture to a rectangle in
> the toplevel's CGImage, and finally the toplevel's CALayer would have the
> system composit the CGImage onscreen. That seems wasteful in a situation
> where speed matters most...
>
> I work with a UIKit implementation for macOS called Chameleon which uses
> CALayer to implement UIView on AppKit (this was long before Apple started
> Catalyst). It works great and UIView can be thought of as the equivalent to
> a tk widget. That's why I believe one CALayer per tk widget is the way to
> go...
>
> Also, this would open the route to tcl/tk on iPadOS and visionOS (if the
> new tk drops HIToolbox).
>
>
> best regards,
> Uwe
>
>
> On 3. Jul 2024, at 18:12, Marc Culler <mar...@gm...> wrote:
>
> 
> Tk Timeline watchers may have noticed a long chain of commits to the
> cgimage_with_crossing branch over the last month.  This announcement is to
> explain what has been going on there.  In brief, that branch contains a
> major change to how drawing works in the macOS port of Tk.  This change
> makes drawing in the macOS port work in a way which is much closer to how
> it works in the other platforms, and much closer to what the generic Tk
> code expects. The result is better performance and increased stability.
>
> The work is based on an idea of Christopher Chavez's.  He realized that
> Apple's Appkit design allowed for an alternative drawing strategy, and
> wrote a proof-of-concept implementation.  I had created a branch containing
> his implementation a couple of years ago.  Recently I merged that branch
> with Tk 9 and then spent a few weeks ironing out wrinkles.  Nicolas Bats,
> Torsten Berg, Steve Landers, and Kevin Walzer kindly offered to help me by
> testing the new implementation on their apps, some of which provide very
> challenging environments for Tk.  The result of this work is in the
> cgimage-with-crossing branch.  (The branch also includes a fix for ticket
> [22349fc78a] which is about <Enter> and <Leave> events - hence the
> reference to crossing in the branch tag.)
>
> The five of us are confident that this is a significant improvement. Some
> highlights are:
>     * Better performance - CPU-intensive apps use about 20% fewer CPU
> cycles
>     * Better conformance - Most runs of the regression test suite on macOS
> 14 show no failures.  This is not close to being the case for the trunk
> branch.
>     * Fewer graphical artifacts (and work continues on those that remain.)
>     * Fewer crashes (none that we know of at the moment.)
>
> Given that the branch has been tested on large and complex apps - all of
> which are working well - this is a major step forwards and we’d like to see
> it tested more widely.  To that end, although we are late in the release
> cycle we are comfortable recommending that this be merged into trunk and
> made part of beta3.  That’s the only way we can guarantee wider testing. Of
> course, if any issues crop up they will be addressed in a timely manner.
> If you are a macOS tkchat user please download and try
> https://www.codebykevin.com/TkChat_Setup_1.5.2.dmg   If you want to try
> the new macOS Tk with your own code and are comfortable building it
> yourself please checkout and build the Tk cgimage_with_crossing branch
>
> The rest of this message gives some more details about the changes.
>
> The main difference is that the new drawing strategy does away with the
> asynchronous drawing via the drawRect method.  A macOS app which uses
> drawRect is supposed to do all of its drawing within the drawRect method,
> which can only be called by the NSApplication object.  The app can request
> that drawRect be called by setting the viewNeedsDisplay flag, but can not
> call drawRect.  The original design of the macOS Aqua port only partially
> complied with this strategy.  In fact it was possible to obtain a valid
> graphics context for drawing to the backing layer of a window's contentView
> even outside of the drawRect method.  The original port would do this, e.g.
> in a widget display proc which is being run as an idle task.  But it would
> also draw in the drawRect method by first generating expose events for all
> widgets that need updates, then processing those expose events to create
> idle tasks, then processing all of those idle tasks immediately.
>
> Obviously this scheme was not what Tk expected.  Nor was it what Apple
> expected.  And Apple put an abrupqt end to half of it with the release of
> macOS Mojave, which made it impossible to obtain a valid graphics context
> outside of the drawRect method. When Tk was first built on Mojave, it
> produced nothing but totally black windows.  Eventually this was worked
> around by arranging that any drawing operation which failed due to an
> invalid graphics context would be rescheduled and also to modify drawRect
> to make it (attempt to) run all of those rescheduled idle tasks.
>
> With the new macOS code it is once again true that Tk always has a valid
> graphics context available and hence can draw at any time.  It draws into a
> CGBitmapImageContext which serves as the backing store for a Tk Window.
> Instead of calling drawRect, it is configured with Apple's other option
> which is to call updateLayer instead.  In the new setup updateLayer
> installs the CGImage as the CALayer of the ContentView of the NSWindow
> which hosts the Tk toplevel, causing the contents of the image to appear in
> the window.  It also creates a new CGImage containing a copy of the window
> in which subsequent drawing operations take place.  This allows drawing
> operations to take place at the expected time and in the expected order.
> That makes for better stability and less unpredictability.  In addition, it
> removes the overhead that arises from attempting a drawing operation,
> having it fail due to an invalid graphics context, rescheduling and
> rerunning the operation.  This accounts for the reduced CPU usage.
>
> - Marc
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
>