From: Vince D. <vin...@gm...> - 2006-03-13 12:09:25
|
A few years ago I remember a lot of discussion around using the modern text rendering engines with TkAqua, to allow proper unicode support and anti-aliasing (both still missing in TkAqua, if I understand correctly). Is anyone still working on this, or using this? Vince. |
From: Benjamin R. <b.r...@tu...> - 2006-03-13 14:48:06
|
Hi Vince, "Vince Darley" writes: > Is anyone still working on this, or using this? It's lingering, because I haven't found time and energy to pursue it further. Several people have been saying that they use it as it is though. benny |
From: Vince D. <vin...@gm...> - 2006-03-13 22:38:34
|
On 3/13/06, Benjamin Riefenstahl <b.r...@tu...> wrote: > [ATSU.patch...] > It's lingering, because I haven't found time and energy to pursue it > further. Several people have been saying that they use it as it is > though. Is there an updated version of the patch? The current one (atsu.patch) fails all over the place on cvs HEAD... cheers, Vince. |
From: Benjamin R. <b.r...@tu...> - 2006-03-14 23:06:48
|
Hi Vince, "Vince Darley" writes: > Is there an updated version of the patch? The current one > (atsu.patch) fails all over the place on cvs HEAD... Yeah, the main problem is probably tkMacOSXFont.c, which is amost completely different. I will try to make a new version of the patch on the weekend. benny |
From: Alastair D. <ala...@si...> - 2006-03-16 09:51:58
|
This patch makes a HUGE improvement to the appearance of text items, much as Jamie's work did for canvas items. In using it with Tk 8.4.9, I haven't particularly noticed any performance problems. Presumably though, if there is a small performance hit, it would be easier to accept this in the alpha status cvs HEAD (Tk 8.5) than in the production core-8-4-branch. When the patch is ready for testing, let me know and I'll be delighted to help, and to quantify the impact (if any) on performance. Best wishes, Alastair Benjamin Riefenstahl wrote: > Hi Vince, > > > "Vince Darley" writes: > >> Is there an updated version of the patch? The current one >> (atsu.patch) fails all over the place on cvs HEAD... >> > > Yeah, the main problem is probably tkMacOSXFont.c, which is amost > completely different. I will try to make a new version of the patch > on the weekend. > > > benny |
From: Vince D. <vin...@gm...> - 2006-03-17 13:58:27
|
On 3/14/06, Benjamin Riefenstahl <b.r...@tu...> wrote: > Yeah, the main problem is probably tkMacOSXFont.c, which is amost > completely different. I will try to make a new version of the patch > on the weekend. Great -- I'm very keen to test. Is the only outstanding "issue" that of the ligature shimmering which can occur when moving the insertion cursor through the text? I'm wondering if some small changes to the text widget to draw the whole line and then draw the insertion cursor 'on top' might resolve that. Vince. |
From: Benjamin R. <b.r...@tu...> - 2006-03-20 14:41:36
|
Hi Vince, Benjamin Riefenstahl writes: > I will try to make a new version of the patch on the weekend. I've done that and attached it to the patch tracker page. benny |
From: Vince D. <vin...@gm...> - 2006-03-20 18:45:34
|
Thanks Benny, I've been testing this out for a bit, and I forgot how much nicer things look! The difference is remarkable! I also don't see any shimmering problem, but now I recall that was with an older version of this. So, I have to ask, what exactly are we waiting for before committing this to cvs (at least to the 8.5 development branch)? Looking through the tracker, it seems we just wanted Jeff to sign off on it. Perhaps I'll drop him a line... cheers, Vince. On 3/20/06, Benjamin Riefenstahl <b.r...@tu...> wrote: > I've done that and attached it to the patch tracker page. > > benny > > |
From: Jeff H. <jeffh@ActiveState.com> - 2006-03-20 19:02:10
|
Vince Darley wrote: > I've been testing this out for a bit, and I forgot how much > nicer things look! The difference is remarkable! I also don't > see any shimmering problem, but now I recall that was with an > older version of this. > > So, I have to ask, what exactly are we waiting for before > committing this to cvs (at least to the 8.5 development > branch)? Looking through the tracker, it seems we just wanted > Jeff to sign off on it. Perhaps I'll drop him a line... Jeff is always lurking on the line. ;) As Vince has given the thumbs up, I will commit to the 8.5 HEAD using Benny's patch tomorrow (PST), if there are no other objections. This will get it into 8.5a4. Jeff |
From: james t. <ti...@ma...> - 2006-03-20 20:27:31
|
On Mar 20, 2006, at 2:01 PM, Jeff Hobbs wrote: > Vince Darley wrote: >> I've been testing this out for a bit, and I forgot how much >> nicer things look! The difference is remarkable! I also don't >> see any shimmering problem, but now I recall that was with an >> older version of this. >> >> So, I have to ask, what exactly are we waiting for before >> committing this to cvs (at least to the 8.5 development >> branch)? Looking through the tracker, it seems we just wanted >> Jeff to sign off on it. Perhaps I'll drop him a line... > > Jeff is always lurking on the line. ;) ...as are many of us :-) > As Vince has given the thumbs up, I will commit to the 8.5 HEAD > using Benny's patch tomorrow (PST), if there are no other > objections. This will get it into 8.5a4. ...great to hear that this is finally coming together! I've been waiting on this before continuing with the coregraphics stuff, and now will be able to get started on this later in the week... ...to recap where it was left (IIRC), I'd submitted changes to most of tkMacOSXdraw.c, but there was a problem with upside-down font rendering when using the coregraphics versions of XCopy*()...I think the next step was to go ahead and remove offscreen gworld usage so that we aren't flipping quartz context coords all the time, and then see where that leaves us (hopefully with right-side-up text)... l8r, jamie |
From: Vince D. <vin...@gm...> - 2006-03-20 21:28:33
|
On 3/20/06, james tittle <ti...@ma...> wrote: > ...great to hear that this is finally coming together! I've been > waiting on this before continuing with the coregraphics stuff, and > now will be able to get started on this later in the week... > > ...to recap where it was left (IIRC), I'd submitted changes to most > of tkMacOSXdraw.c, but there was a problem with upside-down font > rendering when using the coregraphics versions of XCopy*()...I think > the next step was to go ahead and remove offscreen gworld usage so > that we aren't flipping quartz context coords all the time, and then > see where that leaves us (hopefully with right-side-up text)... Out of interest, does this impact (i.e. improve!) any of the menu drawing code? I understand there's some need to move to HIView-based menus to have any support for images in menus and things like that,.. (plus potentially then the ability to tear-off menus) Vince. |
From: Jim I. <ji...@ap...> - 2006-03-20 21:56:58
|
No. The current code just uses the default Mac OS X menu code. So =20 we don't do anything that the standard Mac OS X menus do (we probably =20= don't even do as much, since we haven't played with this code =20 recently). To get things like tearoff menu's and any images that =20 aren't supported by the Mac OS X menu manager, we would have to write =20= a custom menu handler. OTOH, the fact that the new menu manager =20 makes HIViews will make it much easier to implement and support than =20 it was with a custom MDEF... Jim On Mar 20, 2006, at 1:28 PM, Vince Darley wrote: > On 3/20/06, james tittle <ti...@ma...> wrote: >> ...great to hear that this is finally coming together! I've been >> waiting on this before continuing with the coregraphics stuff, and >> now will be able to get started on this later in the week... >> >> ...to recap where it was left (IIRC), I'd submitted changes to most >> of tkMacOSXdraw.c, but there was a problem with upside-down font >> rendering when using the coregraphics versions of XCopy*()...I think >> the next step was to go ahead and remove offscreen gworld usage so >> that we aren't flipping quartz context coords all the time, and then >> see where that leaves us (hopefully with right-side-up text)... > > Out of interest, does this impact (i.e. improve!) any of the menu > drawing code? I understand there's some need to move to HIView-based > menus to have any support for images in menus and things like that,.. > (plus potentially then the ability to tear-off menus) > > Vince. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac Jim Ingham Apple Developer Tools |
From: Daniel A. S. <st...@ic...> - 2006-03-20 23:35:52
|
On 21/03/2006, at 6:01, Jeff Hobbs wrote: >> So, I have to ask, what exactly are we waiting for before >> committing this to cvs (at least to the 8.5 development >> branch)? Looking through the tracker, it seems we just wanted >> Jeff to sign off on it. Perhaps I'll drop him a line... > > Jeff is always lurking on the line. ;) > > As Vince has given the thumbs up, I will commit to the 8.5 HEAD > using Benny's patch tomorrow (PST), if there are no other > objections. This will get it into 8.5a4. you should test tkchat with this, with large buffers, that's what killed my plan to commit last the atsui patch time around, see below. I'll try to run a few test myself with the new patch later today. Vince, Alphatk with very large files loaded might be another good test... a propos 8.5a4, I'm about to commit the patch at https://sourceforge.net/tracker/index.php? func=detail&aid=823329&group_id=10894&atid=110894 which finally implements glob -types {{macintosh type TEXT} {macintosh creator FOOO} hidden} * Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** On 24/02/2004, at 1:37, Daniel A. Steffen wrote: > However, I have found a rather serious issue with performance with > the atsui patch, this showed up while running tkchat with "load at > least 1000 lines of history" checked and using Monaco 9pt text (the > font is probably not relevant). This will create a widget with > ~1000 lines of fairly complex layout, embedded images etc, with > several successive layout runs as more text comes in from the net. > > Without your patch, startup and log loading takes a few seconds, > mainly to http fetch the logs, and text widget performance is no > problem. > With the atsui patch applied however, text layout is so slow that > the inital log loading phase maxes out the machine and takes at > least 20 times as long as without the patch, and generally leads me > to force quit Wish and run the non-atsui version... > Certainly tkchat is fairly unuseable given that it needs to > relayout the widget every 15 seconds after pulling in updates from > the net, and that the text layout tends to take more than 15 > seconds to complete... > > I have run Sampler on tkchat while it is starting up (1st minute or > so), the results are here (on 10.3.2, G4 1Ghz 1MBL3) > http://rutherglen.ics.mq.edu.au/~steffen/tcltk/tkchat.sample.txt > this is filtered to only show routines where more than ~5% of time > was spent, and to ignore the select thread. > > As you can see, 85% of total time is spent in in LayoutDLine(), > inside which TkpMeasureCharsInContext() takes 67% of total time and > and ATSUBreakLine() 15% of total time. > > Looking quickly at the code, it seems that you are throwing away > ATSUTextLayout and ATSUStyle objects after every use, > caching&reusing these was the most important performance hint for > ATSU at last year's WWDC Carbon Performance session (416). Other > hints were to use ATSUBatchBreakLine instead of successive > ATSUBreakLines, to share ATSUStyles among ATSUTextLayout objects, > to create one ATSUTextLayout for each paragraph, and to use > ATSUGetGlyphBounds to get layout bounds. |
From: Vince D. <vin...@gm...> - 2006-03-20 23:52:40
|
On 3/20/06, Daniel A. Steffen <st...@ic...> wrote: > Vince, Alphatk with very large files loaded might be another good > test... That's exactly what I did -- loaded up the Alpha Manual (>100k) and a 7mb text file I have from some other stuff. Both displayed perfectly nicely and quickly... (this is on a new iMac, however) Vince. |
From: Daniel A. S. <st...@ic...> - 2006-03-21 06:28:57
|
On 21/03/2006, at 10:35, Daniel A. Steffen wrote: > On 21/03/2006, at 6:01, Jeff Hobbs wrote: > >>> So, I have to ask, what exactly are we waiting for before >>> committing this to cvs (at least to the 8.5 development >>> branch)? Looking through the tracker, it seems we just wanted >>> Jeff to sign off on it. Perhaps I'll drop him a line... >> >> Jeff is always lurking on the line. ;) >> >> As Vince has given the thumbs up, I will commit to the 8.5 HEAD >> using Benny's patch tomorrow (PST), if there are no other >> objections. This will get it into 8.5a4. > > you should test tkchat with this, with large buffers, that's what > killed my plan to commit last the atsui patch time around, see > below. I'll try to run a few test myself with the new patch later > today. I see the same performance issues as previously with tkchat (latest kit from sdarchive): while loading 1000 lines of chat history, text layout is so slow that it leads to spinning cursor and loss of app responsiveness on my 1GHz G4. This is no doubt due to the continuous re-layouts of tkchat's complex text widget (w/embedded smileys, bold fonts etc) during history loading, but this is something that the QD based text code handles with no trouble. I sharked an optimized unstripped tktest during the history loading phase of tkchat, results below, 92% of total CPU time is spent measuring text, with ATSUNextCursorPosition and ATSUOffsetToPosition being the individual APIs using the most time. Actually drawing the text uses a magnitude less time than measuring it (which is certainly at least partially due to caching by ATSUI) I'll have a more detailed look at TkMacOSXQuarzStartDraw, superficially it appears that it should be easy to improve its performance somewhat with added caching. Despite this, I support committing this to HEAD now, so that others can test if performance is really a major issue in practice, esp since no work has been done on performance since I first reported the issue almost 2 years ago... however, I would hold off on committing to core-8-4-branch until we have a better idea about the performance impact. I have attached an updated patch for HEAD to SF patch 638966 which fixes a number of (mostly cosmetic) small issues with Benny's patch: non-stub exports, printing to stderr, function naming conventions, whitespace, xcode project additions... If there are no objections, I'm happy to commit this along with some other changes that came up while looking into Benny's patch in detail, or Jeff, feel free to commit my patch whenever convenient, my other changes are minor... Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** Shark: system libraries charged to callers Self Total Lib 42.5% 42.5% tktest TkpMeasureCharsInContext 31.8% 31.8% tktest MeasureStringWidth 13.4% 13.4% tktest TkMacOSXQuarzStartDraw 3.4% 3.4% tktest TkpMacOSXLayoutSetString 1.3% 1.3% tktest TkMacOSXQuarzEndDraw Shark: system libraries flattened Self Total Lib 26.1% 26.1% QD ATSUNextCursorPosition 0.0% 26.1% tktest TkpMeasureCharsInContext 23.4% 23.4% QD ATSUOffsetToPosition 0.0% 23.4% tktest MeasureStringWidth 8.8% 8.8% QD ATSUBreakLine 0.0% 8.8% tktest TkpMeasureCharsInContext |
From: Daniel A. S. <st...@ic...> - 2006-03-22 00:50:32
|
On 21/03/2006, at 17:28, Daniel A. Steffen wrote: > I have attached an updated patch for HEAD to SF patch 638966 which > fixes a number of (mostly cosmetic) small issues with Benny's > patch: non-stub exports, printing to stderr, function naming > conventions, whitespace, xcode project additions... > > If there are no objections, I'm happy to commit this along with > some other changes that came up while looking into Benny's patch in > detail done, committed to HEAD . Benny, found a display bug with bidi text (e.g. as in test-atsu.tcl from the SF patch page): placing the cursor in a line with right-to-left text makes a portion of the glyphs in the r2l script disappear, starting at an unpredictable (and changing depending on cursor placement) position and going to the right to the end of the r2l text. Any ideas ? Also, the blinking text cursor in the italic text in test-atsu.tcl should be slanted... (IIRC, ATSUI supports this) Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** |
From: Benjamin R. <b.r...@tu...> - 2006-03-24 13:18:58
|
Hi Daniel, "Daniel A. Steffen" writes: > done, committed to HEAD . Thanks a lot for committing it. I feel kind of bad for not being able for so long to work on the optimizations long enough to get somewhere. > found a display bug with bidi text We don't support bidi yet on any system, that would need some significant changes in the generic code first. So my only goal here was to ensure that bidi text doesn't crash Tk or get us into an endless loop. It was not intended yet by me to be pretty or usefull. > Also, the blinking text cursor in the italic text in test-atsu.tcl > should be slanted... (IIRC, ATSUI supports this) The cursor is drawn by the generic code. A quick test shows that it's upright on Windows also. benny |
From: Daniel A. S. <st...@ic...> - 2006-03-24 15:19:40
|
Benny, have you seen the bugs http://sourceforge.net/tracker/index.php? func=detail&aid=1456157&group_id=12997&atid=112997 http://sourceforge.net/tracker/index.php? func=detail&aid=1325998&group_id=12997&atid=112997 about new test hangs/failures on Tk/X11 introduced by your patch? these should be fixed for the 8.5a4 release... I have just committed a bit of cleanup that moves platform specific code out of the generic file tkTextDisp.c, is the code #ifdef'd by TK_DRAW_IN_CONTEXT and TK_LAYOUT_WITH_BASE_CHUNKS in that file generally applicable or only for TkAqua ? (i.e. should it move to platform specific files ?) Also, I'm confused by the different feature options in tkMacOSXFont.c controlled by the #ifdefs of TK_MAC_COALESCE_LINE/ TK_MAC_USE_MEASURETEXTIMAGE/TK_MAC_USE_GETGLYPHBOUNDS is it correct that all these are undefined ? do we really need all of these different codepaths in that file? On 25/03/2006, at 0:18, Benjamin Riefenstahl wrote: > "Daniel A. Steffen" writes: >> done, committed to HEAD . > > Thanks a lot for committing it. I feel kind of bad for not being able > for so long to work on the optimizations long enough to get somewhere. now that the code is in, if performance becomes enough of a problem, we'll be forced to look at it ;-) >> found a display bug with bidi text > > We don't support bidi yet on any system, that would need some > significant changes in the generic code first. So my only goal here > was to ensure that bidi text doesn't crash Tk or get us into an > endless loop. It was not intended yet by me to be pretty or usefull. ok, much of the bidi actually seems to work ok though, e.g. moving the cursor from l2r to l2r text does the right thing etc, it's just the display that's behaving strangely... >> >> Also, the blinking text cursor in the italic text in test-atsu.tcl >> should be slanted... (IIRC, ATSUI supports this) > > The cursor is drawn by the generic code. A quick test shows that it's > upright on Windows also. understood. Might be worthwhile to look into having the cursor drawn by ATSUI at some point, this would also give us things like the 'split' cursor at bidi intersections etc Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** |
From: Benjamin R. <b.r...@tu...> - 2006-03-27 14:20:52
|
Hi Daniel, all, "Daniel A. Steffen" writes: > have you seen the bugs > http://sourceforge.net/tracker/index.php? > func=detail&aid=1456157&group_id=12997&atid=112997 > http://sourceforge.net/tracker/index.php? > func=detail&aid=1325998&group_id=12997&atid=112997 Should be fixed now, let me all know if it works for you. > is the code #ifdef'd by TK_DRAW_IN_CONTEXT and > TK_LAYOUT_WITH_BASE_CHUNKS in that file generally applicable or only > for TkAqua ? (i.e. should it move to platform specific files ?) Without the code in the #ifdefs, tkTextDisp.c makes an assumption that holds with the current X11 and Windows code as well as with QuickDraw. But that particular assumption doesn't hold with ATSUI. I don't know if the more recent text renderers Uniscribe (Windows) or Pango (X11) would need the same kind of code, if anybody ever wanted to add those to Tk. If we want to remove the #ifdefs, we could just remove the non-TK_DRAW_IN_CONTEXT, non-TK_LAYOUT_WITH_BASE_CHUNKS code paths, the ATSUI code should work in X11 and Windows too. But that would mean that X11 and Windows developers need to understand that code, when they do debugging. I doubt that runtime performance will suffer measurably, but other peoples' mileage may vary on that point. Another idea is to go higher another level in tkTextDisp.c and delegate the line breaking to the platform code. Have a platform specific "paragraph" object that contains all the information that the platform needs to break and draw the text. That would also speed up the ATSUI code, because it would allow the platform code to cache all the layout information in this new object instead of re-layouting the text for each measuring call, as it is now. > Also, I'm confused by the different feature options in > tkMacOSXFont.c controlled by the #ifdefs of TK_MAC_COALESCE_LINE/ > TK_MAC_USE_MEASURETEXTIMAGE/TK_MAC_USE_GETGLYPHBOUNDS is it correct > that all these are undefined ? do we really need all of these > different codepaths in that file? I think we can remove the TK_MAC_COALESCE_LINE branches, they were for a version that didn't have the changes in the generic code. TK_MAC_USE_MEASURETEXTIMAGE and TK_MAC_USE_GETGLYPHBOUNDS are just for alternative implementations of one function, MeasureStringWidth. When I started this, I didn't know clearly which of these possible implementations was the right one for Tk. Now that they are in the CVS history, they can be removed safely. benny |
From: Vince D. <vin...@gm...> - 2006-03-27 14:28:33
|
On 3/27/06, Benjamin Riefenstahl <b.r...@tu...> wrote: > "Daniel A. Steffen" writes: > > have you seen the bugs > > http://sourceforge.net/tracker/index.php? > > func=3Ddetail&aid=3D1456157&group_id=3D12997&atid=3D112997 > > http://sourceforge.net/tracker/index.php? > > func=3Ddetail&aid=3D1325998&group_id=3D12997&atid=3D112997 > > Should be fixed now, let me all know if it works for you. I can confirm this fixes the relevant text widget test failures on Windows = XP. thanks! Vince. |