Menu
▾
▴
tcl-mac
|
From: Kevin W. <kw...@co...> - 2014-09-25 00:51:34
|
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 |
|
From: David Z. <kr...@kr...> - 2014-09-25 08:00:47
|
Hi Kevin, As an extensive Mac Tk user I want to thank you for all the job you've already made and I'll try not to forget to thank you for the future time you'll spend to make Tk available on OS X. I'm not a native english so I might not use the good words but I hope you take the feeling. Kind regards, -- 👤 David Zolli 📧 kr...@kr... |
|
From: Michiel de H. <mjl...@ya...> - 2014-09-25 11:57:04
|
Hi Kevin, First of all, great to hear that you have been working on the Tk-Cocoa code. I am not surprised though that the performance after removing the private API's is less than ideal. Previously I looked in detail at the Tk and Tcl code for Mac. It seems that this code (as you suggest) stays close to the Unix/X11 origins, and doesn't always follow the design principles one would follow for a Cocoa program written from scratch. The two biggest issues I see are: 1) In Tk, the design of the event loop (in particular, processing events in the event loop rather than in the callbacks); 2) In Tcl, the use of a separate thread to monitor file descriptor events. Once these two fundamental issues are fixed, you may find that you get good performance without having to use the private API's. If you are interested, let me know and we can talk about the details. Thanks, -Michiel. -------------------------------------------- On Thu, 9/25/14, Kevin Walzer <kw...@co...> wrote: Subject: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's To: "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...> Date: Thursday, September 25, 2014, 9:50 AM 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 ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Kevin W. <kw...@co...> - 2014-09-25 13:34:58
|
Hello Michiel, Thank you for your feedback. I am certainly happy to hear your thoughts about further improving Tk-Cocoa, but I did need to touch on a couple of things immediately: > 1) In Tk, the design of the event loop (in particular, processing events in the event loop rather than in the callbacks); Tk is building on Tcl's event loop, which is a core feature of the language. > 2) In Tcl, the use of a separate thread to monitor file descriptor events. Tcl supports but does not require threading, and in fact threading is often unnecessary because of the event loop. Re-engineering either of these foundational parts of Tcl would, as I understand it, go far beyond adjusting a platform-specific implementation of the current API (which is what I have been working on). While I'm not a member of the TCT (Tcl's core governing committee) and can't speak for them, I find it hard to imagine that there would be much support for changing the event loop (this would require a large effort across every platform) or for adding threading as a required component. Tcl's inventor, John Osterhout, argued that threads are a bad idea in most instances because of their complexity, and advocated event loops: http://www.cs.utah.edu/~regehr/research/ouster.pdf I realize that threads are very commonly used today, and are a standard part of the Cocoa programmer's toolkit, but some increasingly prominent software projects (cf. node.js) are discovering what Tcl has known for two decades: event loops are powerful. I have only done a little threaded programming myself, and have generally avoided it because Tcl's event loop makes it unnecessary for my needs. Just a few ideas to consider. Looking forward to your thoughts. Thanks, Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Michiel de H. <mjl...@ya...> - 2014-09-25 14:22:02
|
Hi Kevin, I am not suggesting changing any features of Tcl or Tk itself. The only changes would be needed in tclMacOSXNotify.c and in tkMacOSX*.c (mainly tkMacOSXNotify.c). Regarding threading: I think we agree there. I am suggesting to use the event loop instead of a thread to monitor file descriptor events. Best, -Michiel. -------------------------------------------- On Thu, 9/25/14, Kevin Walzer <kw...@co...> wrote: Subject: Re: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's To: "Michiel de Hoon" <mjl...@ya...>, "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...> Date: Thursday, September 25, 2014, 10:34 PM Hello Michiel, Thank you for your feedback. I am certainly happy to hear your thoughts about further improving Tk-Cocoa, but I did need to touch on a couple of things immediately: > 1) In Tk, the design of the event loop (in particular, processing events in the event loop rather than in the callbacks); Tk is building on Tcl's event loop, which is a core feature of the language. > 2) In Tcl, the use of a separate thread to monitor file descriptor events. Tcl supports but does not require threading, and in fact threading is often unnecessary because of the event loop. Re-engineering either of these foundational parts of Tcl would, as I understand it, go far beyond adjusting a platform-specific implementation of the current API (which is what I have been working on). While I'm not a member of the TCT (Tcl's core governing committee) and can't speak for them, I find it hard to imagine that there would be much support for changing the event loop (this would require a large effort across every platform) or for adding threading as a required component. Tcl's inventor, John Osterhout, argued that threads are a bad idea in most instances because of their complexity, and advocated event loops: http://www.cs.utah.edu/~regehr/research/ouster.pdf I realize that threads are very commonly used today, and are a standard part of the Cocoa programmer's toolkit, but some increasingly prominent software projects (cf. node.js) are discovering what Tcl has known for two decades: event loops are powerful. I have only done a little threaded programming myself, and have generally avoided it because Tcl's event loop makes it unnecessary for my needs. Just a few ideas to consider. Looking forward to your thoughts. Thanks, Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Kevin W. <kw...@co...> - 2014-09-25 14:38:08
|
On 9/25/14, 10:21 AM, Michiel de Hoon wrote: > The only changes would be needed in tclMacOSXNotify.c and in tkMacOSX*.c (mainly tkMacOSXNotify.c). > Regarding threading: I think we agree there. I am suggesting to use the event loop instead of a thread to monitor file descriptor events. I'd be interested to hear your suggestions for tkMaCOSXNotify.c. My understanding is that this is mainly a hook into tclMacOSXNotifier.c, which is quite complex. Anything involving threading is currently outside my skill set, so I will defer to those more expert than myself on this. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Michiel de H. <mjl...@ya...> - 2014-09-26 14:38:14
|
Hi Kevin,
Typically in Cocoa the event loop looks something like this:
while (true)
{
NSEvent* event = [NSApp nextEventMatchingMask: NSAnyEventMask
untilDate: date
inMode: NSDefaultRunLoopMode
dequeue: YES];
[NSApp sendEvent: event];
}
This event loop waits for events and dispatches them, but does not actually process them; processing the events should be done in the callbacks. Usually you would want to keep the event loop as simple as possible.
Instead, in tkMacOSXNotify.c nextEventMatchingMask is overridden (which is an odd thing to do in itself) and now calls [NSApp tkProcessEvent:event], thereby processing the event in the event loop rather than in the callback.
You will also see in tkMacOSXNotify.c that sendEvent is also being overridden to keep track of its nesting level, and that [NSApp tkProcessEvent:currentEvent] is being called in TkMacOSXEventsCheckProc, thereby again processing an event in the event loop rather than in the callback. The end result is a very complex event loop, which is likely to be fragile.
I would suggest to move the code in tkProcessEvent to the appropriate callback functions, and after that see how much of the complexity of tkMacOSXNotify.c is still needed.
> My understanding is that this is mainly a hook into tclMacOSXNotifier.c, which is quite complex.
Yes. Therefore I think that tclMacOSXNotifier.c should be fixed first, before touching tkMacOSXNotifier.c
Best,
-Michiel
--------------------------------------------
On Thu, 9/25/14, Kevin Walzer <kw...@co...> wrote:
Subject: Re: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's
To: "Michiel de Hoon" <mjl...@ya...>, "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...>
Date: Thursday, September 25, 2014, 11:38 PM
On 9/25/14, 10:21 AM,
Michiel de Hoon wrote:
> The only changes
would be needed in tclMacOSXNotify.c and in tkMacOSX*.c
(mainly tkMacOSXNotify.c).
> Regarding
threading: I think we agree there. I am suggesting to use
the event loop instead of a thread to monitor file
descriptor events.
I'd
be interested to hear your suggestions for tkMaCOSXNotify.c.
My
understanding is that this is mainly a
hook into tclMacOSXNotifier.c,
which is
quite complex.
Anything
involving threading is currently outside my skill set, so I
will defer to those more expert than myself
on this.
--Kevin
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
|
|
From: Kevin W. <kw...@co...> - 2014-09-26 21:48:37
|
Michiel, On 9/26/14, 10:38 AM, Michiel de Hoon wrote: > Instead, in tkMacOSXNotify.c nextEventMatchingMask is overridden (which is an odd thing to do in itself) and now calls [NSApp tkProcessEvent:event], thereby processing the event in the event loop rather than in the callback. tkProcessEvent is just a wrapper for Cocoa event dispatch; it doesn't run any Tcl procedures. See tkMacOSXEvent.c. I suspect it's designed that way to put everything in one place. See http://core.tcl.tk/tk/tktview?name=3028676fff for discussion by Daniel Steffen of the notifier design. Given the data points I've outlined, I don't think that changing tkProcessEvent will have any useful effect, as it already conforms (as far as I can tell) to your prescription--no actual Tcl events or procedures are executed here. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Michiel de H. <mjl...@ya...> - 2014-09-27 09:06:03
|
Hi Kevin, [Michiel] > Instead, in tkMacOSXNotify.c nextEventMatchingMask is > overridden (which is an odd thing to do in itself) and now > calls [NSApp tkProcessEvent:event], thereby processing > the event in the event loop rather than in the callback. [Kevin] > tkProcessEvent is just a wrapper for Cocoa > event dispatch; it doesn't run any Tcl procedures. > See tkMacOSXEvent.c. > Given the data points I've outlined, I don't think that > changing tkProcessEvent will have any > useful effect, as it already conforms (as far as I can > tell) to your prescription--no actual Tcl events or > procedures are executed here. I think there is a misunderstanding here. I was referring to Cocoa events, not to Tcl events or procedures. In the current design, tkProcessEvent is processing Cocoa events in the event loop rather than in the callback. > See http://core.tcl.tk/tk/tktview?name=3028676fff > for discussion by Daniel Steffen of the > notifier design. Thanks for the pointer. Let me try and see if reorganizing the event loop can fix this bug. If it does, we can discuss again. In the meantime, are there any volunteers to test any new event loop code? In addition to the Tcl/Tk test suite, it would be good to test the code in the real world. Thanks, -Michiel -------------------------------------------- On Sat, 9/27/14, Kevin Walzer <kw...@co...> wrote: Subject: Re: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's To: "Michiel de Hoon" <mjl...@ya...>, "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...> Date: Saturday, September 27, 2014, 6:48 AM Michiel, On 9/26/14, 10:38 AM, Michiel de Hoon wrote: > Instead, in tkMacOSXNotify.c nextEventMatchingMask is overridden (which is an odd thing to do in itself) and now calls [NSApp tkProcessEvent:event], thereby processing the event in the event loop rather than in the callback. tkProcessEvent is just a wrapper for Cocoa event dispatch; it doesn't run any Tcl procedures. See tkMacOSXEvent.c. I suspect it's designed that way to put everything in one place. See http://core.tcl.tk/tk/tktview?name=3028676fff for discussion by Daniel Steffen of the notifier design. Given the data points I've outlined, I don't think that changing tkProcessEvent will have any useful effect, as it already conforms (as far as I can tell) to your prescription--no actual Tcl events or procedures are executed here. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Kevin W. <kw...@co...> - 2014-09-27 12:41:23
|
Michiel,
On 9/27/14, 5:05 AM, Michiel de Hoon wrote:
>
> I think there is a misunderstanding here. I was referring
> to Cocoa events, not to Tcl events or procedures. In the
> current design, tkProcessEvent is processing Cocoa events
> in the event loop rather than in the callback.
It's just a filter that listens for mouse and keyboard events. That's all.
See below:
------
@implementation TKApplication(TKEvent)
/* TODO: replace by +[addLocalMonitorForEventsMatchingMask ? */
- (NSEvent *)tkProcessEvent:(NSEvent *)theEvent {
#ifdef TK_MAC_DEBUG_EVENTS
TKLog(@"-[%@(%p) %s] %@", [self class], self, _cmd, theEvent);
#endif
NSEvent *processedEvent = theEvent;
NSEventType type = [theEvent type];
NSInteger subtype;
NSUInteger flags;
switch ((NSInteger)type) {
case NSAppKitDefined:
subtype = [theEvent subtype];
switch (subtype) {
case NSApplicationActivatedEventType:
break;
case NSApplicationDeactivatedEventType:
break;
case NSWindowExposedEventType:
case NSScreenChangedEventType:
break;
case NSWindowMovedEventType:
break;
case NSWindowWillMoveEventType:
break;
default:
break;
}
break;
case NSKeyUp:
case NSKeyDown:
case NSFlagsChanged:
flags = [theEvent modifierFlags];
processedEvent = [self tkProcessKeyEvent:theEvent];
break;
case NSLeftMouseDown:
case NSLeftMouseUp:
case NSRightMouseDown:
case NSRightMouseUp:
case NSLeftMouseDragged:
case NSRightMouseDragged:
case NSMouseMoved:
case NSMouseEntered:
case NSMouseExited:
case NSScrollWheel:
case NSOtherMouseDown:
case NSOtherMouseUp:
case NSOtherMouseDragged:
case NSTabletPoint:
case NSTabletProximity:
processedEvent = [self tkProcessMouseEvent:theEvent];
break;
#if 0
case NSSystemDefined:
subtype = [theEvent subtype];
break;
case NSApplicationDefined: {
id win;
win = [theEvent window];
break;
}
case NSCursorUpdate:
break;
#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1060
case NSEventTypeGesture:
case NSEventTypeMagnify:
case NSEventTypeRotate:
case NSEventTypeSwipe:
case NSEventTypeBeginGesture:
case NSEventTypeEndGesture:
break;
#endif
#endif
default:
break;
}
return processedEvent;
}
@end
---
> In the meantime, are there any volunteers to test any
> new event loop code? In addition to the Tcl/Tk test suite,
> it would be good to test the code in the real world.
Yes, I would. Test your patch against the sample script submitted with
the bug report I referenced--it reliably causes the Tcl/Tk event loop to
hang. That's what I'm looking to address. Let me know when you have
something to look at.
Thank you,
Kevin
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
|
|
From: Kevan H. <ha...@br...> - 2014-09-27 15:45:26
|
Dear Michiel, > In the meantime, are there any volunteers to test any > new event loop code? Yes, absolutely. I am happy to compile from sources on my MacOS 10.7 laptop, integrate with my code, and run for day-to-day work in our laboratory to see what happens. Right now, I'm still running with TclTk 10.5.8, which I believe is Carbon-based. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/ |
|
From: Kevan H. <ha...@br...> - 2014-09-25 14:43:39
|
Dear Kevin, Thank you for all the work you are doing to keep Tk going on MacOS. > Re-engineering either of these foundational parts of Tcl would, as I > understand it, go far beyond adjusting a platform-specific > implementation of the current API Indeed it would. But the Tcl event loop has one severe limitation, and I believe it's the one Michiel is referring to. I had to build my own event loop on top of Tcl's, because Tcl's would not do the job. The problem with Tcl's event loop is that pending "vwaits" are resolved strictly in reverse order of initiation, and "after" events are ignored during an active vwait. Suppose I am capturing images from a server on the Internet as fast as I can. As soon as one comes in, I post and "after" event to the Tcl event loop. While waiting for each image to arrive, Tcl is in its vwait state, servicing call-backs, but not "after" events, nor will it do anything about other "vwaits" that have terminated. If, during this thge image capture vwait, I happen to press a button on another window that asks for the temperature of the camera, this other data acquisition process begins, but it cannot terminate because the server is busy capturing an image. So it vwaits. But of course the original image capture is what's holding things up, and that won't terminate until this vwait has terminated, which won't happen until it itself has terminated. So we're stuck. There's a name to this kind of stoppage, but I can't remember what it is. All the event loop has to do is return control to whatever vwait or after event occurs first, and all will be well. There are problems associated with such an open-ended event loop, but they are handled with a little discipline, and the resulting structure is far more versatile and efficient. If Tcl has to "vwait" for Cocoa, and Cocoa is assuming that many requests for action come in at the same time, then I can see that the interaction between Tcl and Cocoa cannot work within the Tcl event loop. > I find it hard to imagine that there would be > much support for changing the event loop (this would require a large > effort across every platform) I have written several event loops in my time, one of them in assembler. They are not complicated compared to the kind of detailed graphics code you have been working on. But I agree that there is no chance of the Tcl core team changing the way the event loop is done. I am sure they have many reasons to prefer the strict reverse-order vwait system, although I can't tell you what those reasons might be. Is it possible to build your own graphics event loop with which to interact with Cocoa? I of course speak from a position of near-complete ignorance of the problems you are faced with, so forgive me if I have wasted your time. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/ |
|
From: Will D. <wi...@wj...> - 2014-09-29 15:16:06
|
On Sep 25, 2014, at 9:48 AM, Lars Hellström <Lar...@re...> wrote:
> Kevan Hashemi skrev 2014-09-25 16.17:
>> Dear Kevin,
>>
>> Thank you for all the work you are doing to keep Tk going on MacOS.
>>
>>> Re-engineering either of these foundational parts of Tcl would, as I
>>> understand it, go far beyond adjusting a platform-specific
>>> implementation of the current API
>>
>> Indeed it would. But the Tcl event loop has one severe limitation, and I
>> believe it's the one Michiel is referring to. I had to build my own
>> event loop on top of Tcl's, because Tcl's would not do the job.
>>
>> The problem with Tcl's event loop is that pending "vwaits" are resolved
>> strictly in reverse order of initiation, and "after" events are ignored
>> during an active vwait.
>
> That sounds very much like a misunderstanding, and also like you're using
> far-from-recommended programming practices.
>
> [vwait]s are resolved in reverse order of initialisation, because each is a
> recursive invokation of the event loop. The first advice on using [vwait]
> tends to be to avoid that. And [after] events are being serviced during a
> [vwait], since how else could the following terminate?
>
> % after 500 {incr epoch}; vwait epoch; set epoch
> 1
> % after 500 {incr epoch}; vwait epoch; set epoch
> 2
>
> Your premises appear to be flawed.
>
I'm aware of two canonical uses for vwait:
The first is when a non-event-loop program that needs to enter the event loop for short periods of time; in which case the event loop is not being called recursively. Presumably this case is not a problem.
The second is when popping up modal dialogs such as tk_getOpenFile, where the dialog is truly modal. I see this case as reasonable, especially given that Tk itself does it.
Will
>
> Lars Hellström
>
>
> ------------------------------------------------------------------------------
> Slashdot TV. Videos for Nerds. Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Donald G P. <don...@ni...> - 2014-09-29 15:26:23
|
On 09/29/2014 10:58 AM, Will Duquette wrote: > The second is when popping up modal dialogs such as tk_getOpenFile, where the dialog is truly modal. I see this case as reasonable, especially given that Tk itself does it. Tk is known to do foolish things from time to time. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Lars H. <Lar...@re...> - 2014-09-25 16:48:24
|
Kevan Hashemi skrev 2014-09-25 16.17:
> Dear Kevin,
>
> Thank you for all the work you are doing to keep Tk going on MacOS.
>
>> Re-engineering either of these foundational parts of Tcl would, as I
>> understand it, go far beyond adjusting a platform-specific
>> implementation of the current API
>
> Indeed it would. But the Tcl event loop has one severe limitation, and I
> believe it's the one Michiel is referring to. I had to build my own
> event loop on top of Tcl's, because Tcl's would not do the job.
>
> The problem with Tcl's event loop is that pending "vwaits" are resolved
> strictly in reverse order of initiation, and "after" events are ignored
> during an active vwait.
That sounds very much like a misunderstanding, and also like you're using
far-from-recommended programming practices.
[vwait]s are resolved in reverse order of initialisation, because each is a
recursive invokation of the event loop. The first advice on using [vwait]
tends to be to avoid that. And [after] events are being serviced during a
[vwait], since how else could the following terminate?
% after 500 {incr epoch}; vwait epoch; set epoch
1
% after 500 {incr epoch}; vwait epoch; set epoch
2
Your premises appear to be flawed.
Lars Hellström
|
|
From: Kevan H. <ha...@br...> - 2014-09-26 11:31:21
|
Dear Lars,
> % after 500 {incr epoch}; vwait epoch; set epoch
Thank you for pointing that out: I have after commands being executed
during vwaits myself, so I was mistaken about them.
> and also like you're using far-from-recommended programming
> practices.
I have done very well using far from recommended practices.
> [vwait]s are resolved in reverse order of initialisation, because
> each is a recursive invokation of the event loop.
And why would a vwait give rise to a recursive invokation of the event
loop, when it could simply pass control to a pre-existing event loop?
Having one event loop keeping track of all vwaits and afters and
call-backs would, in my estimation, be far easier to write. And indeed,
I have written such things for embedded systems and been delighted by
how well they perform.
> The first advice on using [vwait] tends to be to avoid that.
Do you mean avoid using vwaits all-together? I guess that is what I have
done, but it seems a pity.
Yours, Kevan
--
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/
|
|
From: Kevin W. <kw...@co...> - 2014-09-25 14:36:16
|
Hi Kevan, On 9/25/14, 10:17 AM, Kevan Hashemi wrote: > Dear Kevin, > > Thank you for all the work you are doing to keep Tk going on MacOS. > >> Re-engineering either of these foundational parts of Tcl would, as I >> understand it, go far beyond adjusting a platform-specific >> implementation of the current API > > Indeed it would. But the Tcl event loop has one severe limitation, and I > believe it's the one Michiel is referring to. I had to build my own > event loop on top of Tcl's, because Tcl's would not do the job. > > The problem with Tcl's event loop is that pending "vwaits" are resolved > strictly in reverse order of initiation, and "after" events are ignored > during an active vwait. > Are these issues specific to Tcl/Tk on the Mac, or to Tcl itself? The former perhaps can be addressed, but the latter is an architectural issue that is above my pay grade. > Is it possible to build your own graphics event loop with which to > interact with Cocoa? I of course speak from a position of near-complete > ignorance of the problems you are faced with, so forgive me if I have > wasted your time. The relevant code is in tkMacOSXNotifer.c (which integrates Tk and Cocoa) and more foundationally in tclMacOSXNotifier.c (which provides the Mac-specific implementation of the event loop). The notifier under Cocoa seems a lot more complex than Carbon. According to Daniel Steffen, it switches between an embedded and an external notifier. If a simpler notifier can be built, I have no idea. I'm assuming no, because much smarter people than myself (Daniel Steffen in particular) came up with the current implementation. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Kevan H. <ha...@br...> - 2014-09-25 15:10:09
|
Dear Kevin, > Are these issues specific to Tcl/Tk on the Mac, or to Tcl itself? They are core issues with Tcl itself, on all platforms, and they are intentional. But the main event loop does perform graphics updates more agressively than "vwait" and "after", and Michiel informs me that there is a separate graphics event loop in tkMacOSXNotifer.c and tclMacOSXNotifier.c, which you say was designed by Daniel Steffen. So I doubt very much that this graphics event loop is plagued by the same limitation as the Tcl core event loop. Nevertheless, when a 2 GHz dual-core machine cannot draw windows fast enough, my guess is that something dysfunctional is going on in the communication with the OS. That's quite apart from the problem of the drawing being correct once it is complete. You say that the private APIs had fixed these problems, which suggests that the problems were not with the fundamentals of tkMacOSXNotifer.c and tclMacOSXNotifier.c. Are there places in the new API-free implementation where one large action has been broken into a large number of smaller actions? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X