Tk Source Code

The new revised text widget renders only low-resolution text in Mac OSX on high resolution displays. In contrast, the classic text widget displays crisp text. 
In the attached screenshots, the difference can be seen. Interestingly, the other widgets display crisp text in both instances.

Yes it's done in a bugfix branch for ticket [82b78e96f5]. Testing welcome.

Thanks for the link and the example. I would still note here that the CLIPPING_IS_WORKING code will be needed on Aqua to avoid fuzzy appearance for the character in the block cursor.

About CLIPPING_IS_WORKING, follow-up to [82b78e96f5].

TK_NO_DOUBLE_BUFFERING patch committed in [447d43a7]. I rely on your testing since I have no way to try myself. Thanks!

Do you plan to assess the CLIPPING_IS_WORKING thing? A dedicated ticket could be better perhaps?

I'll have look at the TK_NO_DOUBLE_BUFFERING patch, many thanks that's great!

Regarding CLIPPING_IS_WORKING, from a quick look at the source code this enters into play when a block cursor is drawn with specific options displaying it. Testing should be rather easy: create a text widget with -blockcursor true and these options set, input some text in it and look at the behavior of the block cursor.

Example code for testing (works in revised_text only, the legacy code does not support the last line):

package require Tk
pack [text .t]
.t insert end "This is a sample text."
.t conf -blockcursor on
.t conf -showinsertforeground yes -insertforeground red

Also, I suggest you read the bottom of this page, where the CLIPPING_IS_WORKING thing is discussed.

I have attached a patch which restores code for TK_NO_DOUBLE_BUFFERING to tkTextDisp.c. Since TK_NO_DOUBLE_BUFFERING is only defined on Tk Aqua, there should be no change in behavior on Windows or X11; some code changes are only for consistency. Although these changes seem to resolve the fuzzy text issue, I would still like to know what needs to be done about the CLIPPING_IS_WORKING code, however I do not know what text widget features need to be used to test that code.

The fuzzy text happens because the revised text widget always draws into a pixmap, and then draws the pixmap to the screen. As discussed in prior tickets like [e2e9ce70b2], pixmaps do not support Retina drawing, and seemingly should not because they are for X11 compatibility. Drawing is only Retina-aware when it is done directly to the screen.

The legacy text widget made some effort to avoid drawing through a pixmap. This appears in code controlled by macro TK_NO_DOUBLE_BUFFERING. The revised text widget removes that code in favor of always drawing to a pixmap; I have yet to locate discussion of why this was done. The revised text widget also uses a pixmap because it claims that XSetClipRectangles() does not work. But I am doubtful that XSetClipRectangles() is broken, particularly now that it is available in Tk Aqua since 8.6.11 (see [b505e5f6a9]). Maybe it is referring to the Xft clipping problem described in [4476fd6144].

Assigning to gcramer on his request.

It may also be a strange side effect. As mentioned, the HiRes capability is saved in the .plist files. These plist files were identical for both trunk and revised_text. The compile lines are also identical. There are minor differences in the linker line due to different object files, which does not look relevant:
--- trunk_compileline.txt	2017-06-13 00:10:48.000000000 +0200
+++ revised_compileline.txt	2017-06-13 00:10:48.000000000 +0200
@@ -1,5 +1,4 @@
 gcc -c -Os -pipe    -Wall -Wwrite-strings -Wsign-compare -Wdeclaration-after-statement -fno-common -DBUILD_tk -I/Users/chris/Programmieren/kbs/sources/tk8.6/unix/../unix -I/Users/chris/Programmieren/kbs/sources/tk8.6/unix/../generic -I/Users/chris/Programmieren/kbs/sources/tk8.6/unix/../bitmaps -I/Users/chris/Programmieren/kbs/sources/tcl8.6/generic -I/Users/chris/Programmieren/kbs/sources/tcl8.6/unix -I/Users/chris/Programmieren/kbs/sources/tk8.6/unix/../macosx -I/Users/chris/Programmieren/kbs/sources/tk8.6/unix/../xlib -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.7\" -DPACKAGE_STRING=\"tk\ 8.7\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_ATFORK=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DMAC_OSX_TCL=1 -DHAVE_COREFOUNDATION=1 -DHAVE_CAST_TO_UNION=1 -DTCL_SHLIB_EXT=\".dylib\" -DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_AVAILABILITYMACROS_H=1 -DHAVE_WEAK_IMPORT=1 -D_DARWIN_C_SOURCE=1 -DMAC_OSX_TK=1     -DTCL_NO_DEPRECATED -std=gnu99 -x objective-c  -mdynamic-no-pic /Users/chris/Programmieren/kbs/sources/tk8.6/unix/../unix/tkAppInit.c
-33 warnings generated.
 rm -f libtkstub8.7.a
 ar cr libtkstub8.7.a tkStubLib.o ttkStubLib.o ; ranlib libtkstub8.7.a
 rm -f libtk8.7.dylib
@@ -24,6 +23,7 @@
 tkAtom.o
 tkBind.o
 tkBitmap.o
+tkBitField.o
 tkBusy.o
 tkClipboard.o
 tkCmds.o
@@ -40,15 +40,16 @@
 tkGeometry.o
 tkGrab.o
 tkGrid.o
+tkIntSet.o
 tkMain.o
 tkObj.o
 tkOldConfig.o
 tkOption.o
 tkPack.o
 tkPlace.o
+tkRangeList.o
 tkSelect.o
 tkStyle.o
-tkUndo.o
 tkUtil.o
 tkVisual.o
 tkWindow.o
@@ -87,8 +88,11 @@
 tkTextDisp.o
 tkTextImage.o
 tkTextIndex.o
+tkTextLineBreak.o
 tkTextMark.o
 tkTextTag.o
+tkTextTagSet.o
+tkTextUndo.o
 tkTextWind.o
 tkStubInit.o
 ttkBlink.o
@@ -227,4 +231,5 @@
 
 gcc -Os -pipe      -prebind -headerpad_max_install_names -Wl,-search_paths_first  tkAppInit.o -L/Users/chris/Programmieren/kbs/buildDarwin/tk8.6 -ltk8.7 \
 		-L/Users/chris/Programmieren/kbs/buildDarwin/lib -ltcl8.6  -lpthread -framework CoreFoundation -framework Cocoa -framework Carbon -framework IOKit    -lz  -lpthread -framework CoreFoundation  -sectcreate __TEXT __info_plist Wish-Info.plist  -o wish
+=== Install /Users/chris/Programmieren/kbs/buildDarwin/tk8.6
 
I see as differences in the macosx folder that some code is #ifdefed whic handles Expose events, but it's hard to believe this can explain this behaviour.
Can it be that there is some kind of Window class identifier that was changed for the text widget?

The crisp screenshot came from core_8_6_branch at the moment of the ticket creation. I reran it on the latest commit and it is still crisp. See attachment.

The text widget is only doing the layout, font rendering will be done in Mac specific stuff (src/maxosx). Currently I don't see a way to fix this in the text widget implementation. You've added a screenshot with crisp text, which version did you use for this screenshot? Did you use trunk 8.7, or one of the official releases? If the latter case is true, then please test the behavior of trunk 8.7. Then we should know whether this problem is related to revised text widget, or to any change in Mac font handling.

The rendering has not changed. It still displays fuzzy text with the most recent checkout.

Bug [39e510f69e] has now been fixed.

Could the OP please try whether this is still happening or not?

Thanks!

> Something in the font creation code is causing Wish to crash on macOS 10.12.

Yes, I think this might be related to bug [39e510f69e]. I suggest to postpone this bug report until the other bug report has been closed.

The deployment version only, yes. See [39e510f69e6e641894d24582c61ba0c99ab21799]. Help appreciated on this btw, thanks.

I am trying to test the revised_text branch to verify this bug and I cannot run Wish. Here is the crashlog:   frame #0: 0x00000001000a97c7 Tk`Tk_AllocFontFromObj + 27
    frame #1: 0x00000001000a4070 Tk`___lldb_unnamed_symbol67$$Tk + 558
    frame #2: 0x00000001000a466a Tk`Tk_SetOptions + 302

Something in the font creation code is causing Wish to crash on macOS 10.12.