[MACTCL] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Kevin W. <kw...@co...>]

Hello all,

I've done another round of commits this week in Tk-Cocoa to improve its 
drawing performance after the removal of the private Cocoa NSView API's.

I must be candid: removing the private API's did result in a degradation 
of Tk's drawing performance under Cocoa. Rendering that was snappy and 
accurate became glitchy, slow, and laggy, with weird artifacts like 
buttons scrolling outside their container window and scrollbars 
appearing in two different places when a window was remapped. Sometimes 
widgets would not remap after a window resized, and in a few instances 
too much resizing would cause a crash.

The last few commits, with some input from Marc Culler, have attempted 
to address the worst of these issues. The button and scrollbar issues 
have been fixed, and some improvement in rendering with window resizing 
and resizing of child windows is now in place. For instance, I've added 
some code to skip over some drawing operations in window resizing, which 
has smoothed things out a bit. Basic user interfaces, such as the ones 
in the Tk demo, render very well with little discernible loss of 
performance. Stability seems fine.

There is still some laggy drawing in more complex interfaces, such as 
ones using paned windows and megawidgets like tablelist. An especially 
heavy-duty app such as TkDiff, which uses a lot of CPU resources to 
implement custom synced scrolling between two windows, is now pretty 
much unusable. This is unavoidable, but unfortunate.

I've spent a lot of hours over the past few weeks becoming acquainted 
with Tk-Cocoa's drawing code, and I regret that I can't wring out much 
more improvement here. Those private API's are undocumented and I don't 
fully understand how they worked or what they actually did, but they did 
add a lot of low-level magic to drawing Tk widgets. If getting the best 
performance for graphic rendering is the goal, including those bits is 
absolutely the right call, and I fully understand why Daniel Steffen 
included them. If an Apple-sponsored open-source project (WebKit) 
includes this code, then it's entirely reasonable for another 
Apple-sponsored open-source project (Tk-Cocoa) to follow suit.

 From a policy standpoint, however, any such inclusion of private API's 
is problematic, especially if Apple changes them under the hood, or if 
Apple enforces restrictions against the use of such API's on their 
platform by third-party projects. Apple has certainly been doing the 
latter. No third-party developer can submit any bundled WebKit code to 
the Mac App Store because of its use of private API's--you are limited 
to linking to the system installation of WebKit. This precludes a lot of 
apps that use WebKit, such as Qt and its QtWebKit module, from the Mac 
App Store. I have also run into this issue with my own commercial apps 
that include Tk. The workaround is to link to the system-installed 
Tcl/Tk frameworks, which on my machine are ancient (8.5.9). This is also 
an inherently fragile solution, because if Apple decided to stop 
bundling Tcl/Tk on OS X, this would greatly limit deployment of any app 
using Tk on the Mac.

The absurdity of Apple's position is quite clear here, but I don't feel 
it can be safely ignored. Apple has greatly benefited our community by 
sponsoring the Cocoa port of Tk--I doubt it would have been written 
otherwise--so I'm not inclined to be too critical of Apple in this 
context.  Part of the reason for the mismatch between Tk and Cocoa is 
that Tk has never really shed its roots in Unix and X11 assumptions. 
That graphic model happened to be a good fit for Carbon, as it is for 
Win32, but it's a poor fit for Cocoa. Re-working Tk's 25-year-old 
architecture isn't likely to happen, so we have to make the best with 
what we have. Removing the private API's is a necessary, but 
unpalatable, compromise for the platform's requirements, one somewhat 
mitigated by the last few rounds of commits.

For those who have read this far, thanks for your continued support, and 
my apologies that we cannot do much better than the current state of 
affairs. As always, I welcome your feedback, and just as importantly, 
your code contributions--Marc Culler's patches have been hugely 
important in the recent improvements I've been able to commit.

Thanks,
Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com