tcl-mac

[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no updates, multiple drawing of buttons

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

[repost from c.l.t, sent there by mistake]

Hi all,

I've been wrestling with a bug in Tk-Cocoa that is leaving me stumped, 
and I'm wondering if anyone else has any insight.

I wrote this code to test some minor updates to the wm manage/wm forget 
commands that I've implemented for Tk. The code should work under the 
latest release of ActiveTcl, if you don't have that version.

The bug I'm trying to track down is an issue with the screen redraw. 
When you run this code in Wish, and click the "dock" button, you'll get 
a new toplevel, per the [wm manage] command. Close the window, and the 
widget is packed again. Click the "dock" button again, and you may see 
*two* buttons drawn in the new toplevel, and/or some blurry lines/spots 
that indicate visual trash that hasn't been cleaned up. It doesn't 
happen on the first firing of wm forget/wm manage, but on subsequent ones.

The code below is the simplest illustration of issues with sluggish or 
incomplete screen redraw that I can come up with. I've observed this in 
Tk-Cocoa for a couple of years now, but others are seeing it also 
(Torsten Berg reported the bug on c.l.t), and it seems to be an issue.

Daniel, if you're reading, any suggestions about where in the source 
tree I should look at to deal with this? Getting deep into the internals 
of Tk drawing is a bit out of my depth, and any pointers are appreciated.

Code is below. (I *hope* this code doesn't display another bug, which is 
a hard crash under certain circumstances with the wm forget command, but 
that's another issue.) Thanks.

proc tearoff {w} {
     global docked
     pack forget $w
     wm manage $w
     update
     wm protocol $w WM_DELETE_WINDOW [list untearoff $w]

     }
     proc untearoff {w} {
     wm forget $w
     pack $w
     }


pack [frame .f]
pack [button .f.b -text "Dock" -command {tearoff .f}]

--Kevin

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

Re: [MACTCL] Screen redraw in Tk-Cocoa--sluggish, no updates, multiple drawing of buttons

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

Hi all,

With some additional input from Daniel Steffen off-list, and doing some 
additional review of recent bug reports with Tk-Coca, I've undertaken to 
dig into the issues I first mentioned in this thread, of slow redraw, 
freezes, crashes, etc.

First, I'm setting aside the issue of weird double-renditions of buttons 
that appear in the [wm manage] and [wm forget] commands, because there 
appear to be additional issues with those commands on Aqua, as reported 
here:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/34f8d65481c42589#

I'm the one who implemented these commands for Aqua, based on their 
implementations in Windows and X11, but there appear to be issues with 
the commands' stability that are intrinsically in conflict with the way 
windows are handled on OS X--that, according to Daniel, is why these 
were not supported from the start on Aqua. So, if you use these 
commands, proceed with caution.

Otherwise, there actually appear to be several issues here, some of 
which are related, but not all. Below are some relevant bug reports at 
SF and on c.l.t:

Event processing, bug 3028676:
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3028676&group_id=12997

Slow refresh/redrawing, bug 3166688:
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3166688&group_id=12997

Tk locks up when throwing bgerror with menu selection, bug 3285355:
http://sourceforge.net/tracker/?func=detail&aid=3285355&group_id=12997&atid=112997

Slow redraw in text widget:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/ae42036026976a1e#

I've seen all of these myself in one form or another.

To investigate the drawing issues, Daniel suggested running Tk in a 
"drawing debugger" mode, and which I did. Running the Wish demo in the 
debugger mode and also the sample script in 3166688 above, I saw no 
discernible issue with the accuracy of drawing and refreshing. However, 
in the case of 3166688's script (see gui-frames-noupdate.tcl at the SF 
link), the drawing was an order of magnitude slower than in Tk-Carbon. 
(One of the widgets used a randomly generated range of colors to 
exercise the widget.)  The bug report of slow redraw in the text widget 
at c.l.t is a bit different, in that the widget is very slow to refresh 
itself and sometimes requires a mouse click or a window resize to fully 
update itself.

The bgerror issue in bug 3285355 above, which causes Tk to freeze when 
trying to display a modal dialog in reponse to an error thrown from a 
menu or keyboard shortcut, is not so much a drawing error as an event 
processing issue; it seems that events are not being processed. That is 
also the issue directly explored in bug 3028676; if you look at the 
comments there, you see that Daniel indicates the event processing loop 
in Tk-Cocoa is quite different than in Tk-Carbon, in that the event 
notifier is both an embedded and embedding notifier (and presumably more 
complicated than the one in Carbon).

Looking at the confluence of all these bug reports, I'd like to put 
forward two observations about Tk-Cocoa:

1. The event loop/notify cycle, presumably because of its greater 
complexity, is more fragile and more prone to bugs, and this can cause 
issues with application responsiveness in such contexts as the 
bgerror/menu shortcut one.
2. In some cases Tk-Cocoa is noticably slower to redraw and refresh 
widgets than in Tk-Carbon. Whether this is because of its different 
drawing model (adapted from WebKit, which re-implements major portions 
of the NSView drawing model), its more complicated event 
loop/notification cycle, or some complex interaction between the two, 
Tk-Cocoa sometimes feels more sluggish than Tk-Carbon.

Having identified these issues, I am not sure there is anything that can 
be done to address them at a deep level. Many of Daniel's design 
decisions in developing the Cocoa port of Tk were driven by significant 
differences between the Cocoa model of applications and Tk's, and many 
of the performance/responsiveness issues we are now seeing are likely an 
unavoidable consequence of adapting Tk to fit the Cocoa way of doing 
things. The reason Carbon was initially chosen for the Tk-Aqua port is 
that it more closely matches the Tk (and presumably Xlib) model of doing 
things; Apple, of course, mandated (and, in Tk's case, funded) the 
switch to Cocoa. In any event, even if it is possible to optimize or 
improve these issues, I do not feel qualified to do so, as it touches on 
Tk-Cocoa's internals at such a low level. I am competent to fix simple 
bugs, and have closed many of them in recent months, but re-architecting 
major portions of Tk-Cocoa is not my forte.

One thing that can be done is to experiment with "update idletasks," 
"after 100," etc. in some contexts; if you look at the bug reports 
above, some people have found success with such event-loop manipulation. 
I've dealt with the bgerror issue in my own applications by redefining 
the bgerror procedure to write to standard output.

Of course, if anyone else is inclined to take a closer look at any of 
these issues and submit patches, I will be glad to review and include 
them. However, in the near future  I am probably going to close many of 
the currently reported bugs at SF as unfixable, unless someone else is 
able to present a solution to them.

As always, other viewpoints are appreciated.

Thanks,
Kevin

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

[MACTCL] Have to click twice

[Steven <ste...@ya...>]

With multi window apps, a friend has been lamenting having to click twice when switching between windows (ie - one click to get focus, another click to activate a widget), which is unlike on Linux and Windows.

I tried declaring secondary toplevels as transient, but to no avail.

... So now my only idea is an ugly hack like what i've outline below. We collect the FocisIn click, and generate an extra Button event at the same window location. I havent written anything yet.

Has anyone successfully tried this, or worked around the "have to click twice" issue in some other way ? Perhaps it's possible with an Operating System tweak, or even a custom compilation of Tcl, which we already include with our App (http://scidvspc.sf.net) because of problems with Snow Leopard's Wish 8.5.7.

Cheers, Steven Atkinson

---------------------------------------

# Try to catch focus-in button press, and pass to widget
# (rough outline only)

rename toplevel tk_toplevel

proc toplevel {w args} {
  tk_toplevel $w $args  
  bind $w <FocusIn> {GenerateExtraClick %W %x %y}
}

proc GenerateExtraClick {w x y} {
  if {[focus was achieved with button click ?]} {
    event generate $w <Button-1> -button 1 -rootx $x -rooty $y
  }
  # May-be necessary ?
  bind $w <FocusIn> {} 
  bind $w <FocusOut> {
    bind $w <FocusIn> {Generate_extra_click %W %x %y}
  }
}

Re: [MACTCL] Have to click twice

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

On 9/8/11 8:05 PM, Steven wrote:
> With multi window apps, a friend has been lamenting having to click twice when switching between windows (ie - one click to get focus, another click to activate a widget), which is unlike on Linux and Windows.
>
> I tried declaring secondary toplevels as transient, but to no avail.
>
> ... So now my only idea is an ugly hack like what i've outline below. We collect the FocisIn click, and generate an extra Button event at the same window location. I havent written anything yet.
>
> Has anyone successfully tried this, or worked around the "have to click twice" issue in some other way ? Perhaps it's possible with an Operating System tweak, or even a custom compilation of Tcl, which we already include with our App (http://scidvspc.sf.net) because of problems with Snow Leopard's Wish 8.5.7.
>
> Cheers, Steven Atkinson

I'm not sure I see the issues you are reporting. I have downloaded your 
app and can click on a button in a background window ("click-through" 
behavior) just fine.

In any event, the build of Tk you are using appears to be obsolete--it's 
based on Carbon as far as I can tell. No bugs in that branch of Tk are 
being fixed at this point.

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

Re: [MACTCL] Have to click twice

[Steven <ste...@ya...>]

Thanks for the reply :)

Steven wrote:

> > With multi window apps, a friend has been lamenting
> having to click twice when switching between windows (ie -
> one click to get focus, another click to activate a widget),
> which is unlike on Linux and Windows.
...
> > Has anyone successfully tried this, or worked around
> the "have to click twice" issue in some other way ? Perhaps
> it's possible with an Operating System tweak, or even a
> custom compilation of Tcl, which we already include with our
> App (http://scidvspc.sf.net) because of problems with Snow
> Leopard's Wish 8.5.7.

Kevin wrote:

> I'm not sure I see the issues you are reporting. I have
> downloaded your
> app and can click on a button in a background window
> ("click-through"
> behavior) just fine.

This is very suprising. On our systems, with numerous Tcl builds  we haven't been able to do this. 

> In any event, the build of Tk you are using appears to be
> obsolete--it's
> based on Carbon as far as I can tell. No bugs in that
> branch of Tk are
> being fixed at this point.

And this is also very suprising. While i'm mainly concerned with finding a click-through solution, (as we now longer have known bugs with our built-in framework), i have to comment on this.

Considering the amount and severity of bugs in tk-cocoa (re the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no updates, multiple drawing of buttons" thread), i can't imagine how you suggest using it for our project, which handles huge databases and is a serious Chess database app - generally rivalling commercial products.

Reliability is everything in a database, and bugs in OSX Tcl is definitely the issue for us. The 32 bit build we use is the only one that works for us, after weeks and months of trial and error, messing with SnowLeopard's Wish, and learning how to build our own. Our app is very resource intensive, and probably exposes lots of frailities in OSX wish that are otherwise hard to pin-point.

(For example, on wish-8.5.7 it performs perfectly on Linux and Windows, but using Snow-Leopards Wish-8.5.7, the program crashes shortly after loading any moderate sized PGN file or database. And exhibits *unusual* behaviour and coredumps when using tk_dialog shortly before program exit. The program can be linked against your systems Framework by downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz ), and installing into /usr/local with "./configure && make install && scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a small database containing 30,000 chess games. The maximum database size is ~ 16 million.)

Anyway, i understand your desire to move people to Cocoa, but considering the issues you have, which reflect our frustrating testing .... we are definitely using Carbon. ( And I should mention my OSX packager feverently wanted to use Cocoa, but gave in after much frustration).

We could suggest using Scid vs. Mac as a stress test for Tcl/Tk. It does so admirably ;> But i've found debugging it's coredumps very hard, though OS X *does* provide detailed backtraces, and the OS has never crashed for either of us i think.

----------------------

Sorry to take up so much of your time, but back to our small problem which hardly matters really ;>

I thought it was a known fact that Tk toplevels didn't have click-through on OS X. (ie - when one ScidvsMac toplevel has focus, clicking a button on another toplevel (say, the game-list) doesn't actuate the button, but merely gives the other toplevel focus.)

I don't suppose others can verify whether the App 
( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download) which should definitely link to our Tk Framework AFAIK, "clicks through" (or not) for them. 

The App is an i386/PPC universal, (though PPC seems immune to all of the serious bugs that we had, despite testing with tcl-8.5.7 on the PPC box).

cheers, Steven

[MACTCL] OS X Performance

[Steven <ste...@ya...>]

I took my new intel macbook on holidays last week.
OS X is such a great operating system. But its slow and buggy Wish is possibly the only thing stopping me from leaving Linux.

Can anyone summarise technically why Wish is so slow at redrawing on OSX?

I guess it's to do with OSX's amazing desktop image compositing layer, but have never found anything that explicitly explains it.

Thanks for your work.

Steven


--- On Fri, 9/9/11, Steven <ste...@ya...> wrote:

> From: Steven <ste...@ya...>
> Subject: Re: [MACTCL] Have to click twice
> To: kw...@co...
> Cc: Tc...@li..., "Gilles PLUME" <pl...@ma...>
> Received: Friday, 9 September, 2011, 4:27 PM
> Thanks for the reply :)
> 
> Steven wrote:
> 
> > > With multi window apps, a friend has been
> lamenting
> > having to click twice when switching between windows
> (ie -
> > one click to get focus, another click to activate a
> widget),
> > which is unlike on Linux and Windows.
> ...
> > > Has anyone successfully tried this, or worked
> around
> > the "have to click twice" issue in some other way ?
> Perhaps
> > it's possible with an Operating System tweak, or even
> a
> > custom compilation of Tcl, which we already include
> with our
> > App (http://scidvspc.sf.net) because of problems with Snow
> > Leopard's Wish 8.5.7.
> 
> Kevin wrote:
> 
> > I'm not sure I see the issues you are reporting. I
> have
> > downloaded your
> > app and can click on a button in a background window
> > ("click-through"
> > behavior) just fine.
> 
> This is very suprising. On our systems, with numerous Tcl
> builds  we haven't been able to do this. 
> 
> > In any event, the build of Tk you are using appears to
> be
> > obsolete--it's
> > based on Carbon as far as I can tell. No bugs in that
> > branch of Tk are
> > being fixed at this point.
> 
> And this is also very suprising. While i'm mainly concerned
> with finding a click-through solution, (as we now longer
> have known bugs with our built-in framework), i have to
> comment on this.
> 
> Considering the amount and severity of bugs in tk-cocoa (re
> the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no
> updates, multiple drawing of buttons" thread), i can't
> imagine how you suggest using it for our project, which
> handles huge databases and is a serious Chess database app -
> generally rivalling commercial products.
> 
> Reliability is everything in a database, and bugs in OSX
> Tcl is definitely the issue for us. The 32 bit build we use
> is the only one that works for us, after weeks and months of
> trial and error, messing with SnowLeopard's Wish, and
> learning how to build our own. Our app is very resource
> intensive, and probably exposes lots of frailities in OSX
> wish that are otherwise hard to pin-point.
> 
> (For example, on wish-8.5.7 it performs perfectly on Linux
> and Windows, but using Snow-Leopards Wish-8.5.7, the program
> crashes shortly after loading any moderate sized PGN file or
> database. And exhibits *unusual* behaviour and coredumps
> when using tk_dialog shortly before program exit. The
> program can be linked against your systems Framework by
> downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz
> ), and installing into /usr/local with "./configure
> && make install && scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a
> small database containing 30,000 chess games. The maximum
> database size is ~ 16 million.)
> 
> Anyway, i understand your desire to move people to Cocoa,
> but considering the issues you have, which reflect our
> frustrating testing .... we are definitely using Carbon. (
> And I should mention my OSX packager feverently wanted to
> use Cocoa, but gave in after much frustration).
> 
> We could suggest using Scid vs. Mac as a stress test for
> Tcl/Tk. It does so admirably ;> But i've found debugging
> it's coredumps very hard, though OS X *does* provide
> detailed backtraces, and the OS has never crashed for either
> of us i think.
> 
> ----------------------
> 
> Sorry to take up so much of your time, but back to our
> small problem which hardly matters really ;>
> 
> I thought it was a known fact that Tk toplevels didn't have
> click-through on OS X. (ie - when one ScidvsMac toplevel has
> focus, clicking a button on another toplevel (say, the
> game-list) doesn't actuate the button, but merely gives the
> other toplevel focus.)
> 
> I don't suppose others can verify whether the App 
> ( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download)
> which should definitely link to our Tk Framework AFAIK,
> "clicks through" (or not) for them. 
> 
> The App is an i386/PPC universal, (though PPC seems immune
> to all of the serious bugs that we had, despite testing with
> tcl-8.5.7 on the PPC box).
> 
> cheers, Steven
> 
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how
> and why cloud
> computing security and archiving is rapidly being adopted
> across the IT 
> space for its ease of implementation, lower cost, and
> increased 
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

Re: [MACTCL] OS X Performance

[Hans-Christoph S. <ha...@at...>]

Are you using the new Tk/Cocoa that is included with 10.6?  That is
supposed to be much faster.  For < 10.6, you can build it yourself, but
it is a separate branch, unless you are using Tcl/Tk 8.6

.hc

On Mon, 2011-10-10 at 14:15 -0700, Steven wrote:
> I took my new intel macbook on holidays last week.
> OS X is such a great operating system. But its slow and buggy Wish is possibly the only thing stopping me from leaving Linux.
> 
> Can anyone summarise technically why Wish is so slow at redrawing on OSX?
> 
> I guess it's to do with OSX's amazing desktop image compositing layer, but have never found anything that explicitly explains it.
> 
> Thanks for your work.
> 
> Steven
> 
> 
> --- On Fri, 9/9/11, Steven <ste...@ya...> wrote:
> 
> > From: Steven <ste...@ya...>
> > Subject: Re: [MACTCL] Have to click twice
> > To: kw...@co...
> > Cc: Tc...@li..., "Gilles PLUME" <pl...@ma...>
> > Received: Friday, 9 September, 2011, 4:27 PM
> > Thanks for the reply :)
> > 
> > Steven wrote:
> > 
> > > > With multi window apps, a friend has been
> > lamenting
> > > having to click twice when switching between windows
> > (ie -
> > > one click to get focus, another click to activate a
> > widget),
> > > which is unlike on Linux and Windows.
> > ...
> > > > Has anyone successfully tried this, or worked
> > around
> > > the "have to click twice" issue in some other way ?
> > Perhaps
> > > it's possible with an Operating System tweak, or even
> > a
> > > custom compilation of Tcl, which we already include
> > with our
> > > App (http://scidvspc.sf.net) because of problems with Snow
> > > Leopard's Wish 8.5.7.
> > 
> > Kevin wrote:
> > 
> > > I'm not sure I see the issues you are reporting. I
> > have
> > > downloaded your
> > > app and can click on a button in a background window
> > > ("click-through"
> > > behavior) just fine.
> > 
> > This is very suprising. On our systems, with numerous Tcl
> > builds  we haven't been able to do this. 
> > 
> > > In any event, the build of Tk you are using appears to
> > be
> > > obsolete--it's
> > > based on Carbon as far as I can tell. No bugs in that
> > > branch of Tk are
> > > being fixed at this point.
> > 
> > And this is also very suprising. While i'm mainly concerned
> > with finding a click-through solution, (as we now longer
> > have known bugs with our built-in framework), i have to
> > comment on this.
> > 
> > Considering the amount and severity of bugs in tk-cocoa (re
> > the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no
> > updates, multiple drawing of buttons" thread), i can't
> > imagine how you suggest using it for our project, which
> > handles huge databases and is a serious Chess database app -
> > generally rivalling commercial products.
> > 
> > Reliability is everything in a database, and bugs in OSX
> > Tcl is definitely the issue for us. The 32 bit build we use
> > is the only one that works for us, after weeks and months of
> > trial and error, messing with SnowLeopard's Wish, and
> > learning how to build our own. Our app is very resource
> > intensive, and probably exposes lots of frailities in OSX
> > wish that are otherwise hard to pin-point.
> > 
> > (For example, on wish-8.5.7 it performs perfectly on Linux
> > and Windows, but using Snow-Leopards Wish-8.5.7, the program
> > crashes shortly after loading any moderate sized PGN file or
> > database. And exhibits *unusual* behaviour and coredumps
> > when using tk_dialog shortly before program exit. The
> > program can be linked against your systems Framework by
> > downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz
> > ), and installing into /usr/local with "./configure
> > && make install && scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a
> > small database containing 30,000 chess games. The maximum
> > database size is ~ 16 million.)
> > 
> > Anyway, i understand your desire to move people to Cocoa,
> > but considering the issues you have, which reflect our
> > frustrating testing .... we are definitely using Carbon. (
> > And I should mention my OSX packager feverently wanted to
> > use Cocoa, but gave in after much frustration).
> > 
> > We could suggest using Scid vs. Mac as a stress test for
> > Tcl/Tk. It does so admirably ;> But i've found debugging
> > it's coredumps very hard, though OS X *does* provide
> > detailed backtraces, and the OS has never crashed for either
> > of us i think.
> > 
> > ----------------------
> > 
> > Sorry to take up so much of your time, but back to our
> > small problem which hardly matters really ;>
> > 
> > I thought it was a known fact that Tk toplevels didn't have
> > click-through on OS X. (ie - when one ScidvsMac toplevel has
> > focus, clicking a button on another toplevel (say, the
> > game-list) doesn't actuate the button, but merely gives the
> > other toplevel focus.)
> > 
> > I don't suppose others can verify whether the App 
> > ( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download)
> > which should definitely link to our Tk Framework AFAIK,
> > "clicks through" (or not) for them. 
> > 
> > The App is an i386/PPC universal, (though PPC seems immune
> > to all of the serious bugs that we had, despite testing with
> > tcl-8.5.7 on the PPC box).
> > 
> > cheers, Steven
> > 
> > ------------------------------------------------------------------------------
> > Why Cloud-Based Security and Archiving Make Sense
> > Osterman Research conducted this study that outlines how
> > and why cloud
> > computing security and archiving is rapidly being adopted
> > across the IT 
> > space for its ease of implementation, lower cost, and
> > increased 
> > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> > _______________________________________________
> > Tcl-mac mailing list
> > tc...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-mac
> > 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] OS X Performance

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

Hi Steven,

Sorry, I must have missed your earlier e-mail; I don't remember seeing 
it. Let me address your concerns below.

On 10/10/11 5:15 PM, Steven wrote:
> I took my new intel macbook on holidays last week.
> OS X is such a great operating system. But its slow and buggy Wish is possibly the only thing stopping me from leaving Linux.
>
> Can anyone summarise technically why Wish is so slow at redrawing on OSX?
>
> I guess it's to do with OSX's amazing desktop image compositing layer, but have never found anything that explicitly explains it.
>
> Thanks for your work.
>
> Steven

This is a very general statement that is certainly not accurate in all 
respects. I occasionally see redraw issues with Wish-Cocoa, but not 
often. It's usually when we're dealing with instances of recent bugs 
logged at the tracker--things involving tk_wait, for instance--that 
involve low-level issues surrounding the integration between the Tk 
event loop and Cocoa. There are no easy fixes for these issues, as I've 
indicated on the mailing list.

Let me address the earlier comments as well:

>> Considering the amount and severity of bugs in tk-cocoa (re
>> the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no
>> updates, multiple drawing of buttons" thread), i can't
>> imagine how you suggest using it for our project, which
>> handles huge databases and is a serious Chess database app -
>> generally rivalling commercial products.

The reason I suggest using it is that the Carbon branch of Tk is 
unmaintained and unsupported, and if you want 64-bit, unavailable. It's 
a judgment call and if you don't need 64-bit performance, by all means 
use the Carbon port.

>>
>> Reliability is everything in a database, and bugs in OSX
>> Tcl is definitely the issue for us. The 32 bit build we use
>> is the only one that works for us, after weeks and months of
>> trial and error, messing with SnowLeopard's Wish, and
>> learning how to build our own. Our app is very resource
>> intensive, and probably exposes lots of frailities in OSX
>> wish that are otherwise hard to pin-point.

Quite likely.

>>
>> (For example, on wish-8.5.7 it performs perfectly on Linux
>> and Windows, but using Snow-Leopards Wish-8.5.7, the program
>> crashes shortly after loading any moderate sized PGN file or
>> database. And exhibits *unusual* behaviour and coredumps
>> when using tk_dialog shortly before program exit. The
>> program can be linked against your systems Framework by
>> downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz
>> ), and installing into /usr/local with "./configure
>> &&  make install&&  scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a
>> small database containing 30,000 chess games. The maximum
>> database size is ~ 16 million.)

I did build the app and test it against the database you linked to, and 
didn't see any issues or crashes, but obviously YMMV. I'm also working 
on Lion, where the system Tk (Cocoa) is much more stable than the one 
bundled with Snow Leopard. (The Snow Leopard build was more a beta 
version, with lots of bugs fixed later, but Apple doesn't update Tk 
except at new versions of the OS.

>>
>> Anyway, i understand your desire to move people to Cocoa,
>> but considering the issues you have, which reflect our
>> frustrating testing .... we are definitely using Carbon. (
>> And I should mention my OSX packager feverently wanted to
>> use Cocoa, but gave in after much frustration).

As I said, you have very good reasons for staying with Carbon.


>>
>> I thought it was a known fact that Tk toplevels didn't have
>> click-through on OS X. (ie - when one ScidvsMac toplevel has
>> focus, clicking a button on another toplevel (say, the
>> game-list) doesn't actuate the button, but merely gives the
>> other toplevel focus.)

This may have been true in earlier versions of Tk, but not recently. I 
don't see this issue in my Cocoa build of the app.
>>
>> I don't suppose others can verify whether the App
>> ( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download)
>> which should definitely link to our Tk Framework AFAIK,
>> "clicks through" (or not) for them.
>>
>> The App is an i386/PPC universal, (though PPC seems immune
>> to all of the serious bugs that we had, despite testing with
>> tcl-8.5.7 on the PPC box).

As you are probably aware, PPC is also obsolete, but if it works there, 
great!

--Kevin

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