[Cuis-dev] Making Cuis Unicode-only and VectorGraphics-only. (was Re: Alternative arrows)

[Gerald Klix]

On 19.10.22 21:41, Juan Vuletich via Cuis-dev wrote:
> Hi Gerald,
> 
> On 10/18/2022 4:45 PM, Gerald Klix via Cuis-dev wrote:
>> Hi Juan,
>>
>> please see below.
>>
>> On 18.10.22 21:02, Juan Vuletich wrote:
>>> ...
>>>
>>> Now that the VectorEnginePlugin is in the official VMs, it means we 
>>> can count on it. 
>> In theory yes, I presume the life-typing-VM may suffer,
>> but IHMO that's a side issue.
> 
> That is important, of course. I think that the live-typing VM should 
> have no trouble in updating to the latest from OpenSmalltalk, including 
> VectorEnginePlugin.
I thought so, therefore I considered it a side-issue.
BTW (and the danger of repeating myself): Life-Type should
be done at the byte-code level.
> 
>> While the VectorEnginePlugin is fast enough for medium size
>> monitors, I often experience noticeable, sometimes annoying delays,
>> when I use it. (I know, my bad:
>> Display boundingBox ->  0 at 0 corner: 4320 at 3840).
>> “Annoying” mean, I loose input keystrokes.
The problem is, that Haver's keyboard focus algorithm
sometimes is slow to activate right window.
After such a memory tight situation, I often find myself
typing “to” the wrong window and some times to the desktop.
In the later case -- happens mostly with StringRequestMorphs
and the like -- I lose keystrokes.
> 
> Wow, that bad? On what platform are you?
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              12
On-line CPU(s) list: 0-11
Thread(s) per core:  2
Core(s) per socket:  6
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               63
Model name:          Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Stepping:            2
CPU MHz:             1224.188
CPU max MHz:         3900.0000
CPU min MHz:         1200.0000
BogoMIPS:            6732.80
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            15360K
NUMA node0 CPU(s):   0-11
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good 
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm 
abm cpuid_fault epb invpcid_single pti intel_ppin ssbd ibrs ibpb stibp 
tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 
avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm 
ida arat pln pts md_clear flush_l1d

IHMO: Even if it's already 6 years old, a grandpa in terms
of hardware-„Fortschritt“, it's still much faster than any
Raspberry Pi money can buy.

> 
>> It clearly becomes better, when less text has to be displayed
>> and it stays bad, once I had a stack-overflow (there is at
>> least one memory leak caused by stack overflows, but
>> that's a different story).
>>
>> In a nutshell: I would love to help to make vector graphics
>> faster!
> 
> Yes. We need to work on performance. We cant flip the switch if it is 
> too slow.
> 
>>> So, what I want to do is to make the "Use Unicode" preference the 
>>> default and only behavior, and actually remove support for ISO 8859 
>>> files (and StrikeFonts, and a lot of the older stuff). And if 
>>> everything is Unicode, then there's no need to have these special 
>>> glyphs for $_ and $^. We could use instead a real Unicode left arrow 
>>> for assignment, and just remove support for $_ for assignment. (Using 
>>> := would still be possible). All this "Smalltalk-80 glyphs" kludge 
>>> would go away.
>> That would be cool!
>>>
>>> What do you think?
>>>
>>> If we decide to go in this direction, it may make sense to 
>>> temporarily disable the "Smalltalk-80 glyphs", at least if you want 
>>> to use the Unicode arrows for something else.
>> Does that mean, I will see underscores in this phase?
>> Hopefully not.
>> I confess, I did not know, that there is another assignment operator
>> than “:=” before I used Cuis :»
> 
> Well, as usual, we need to do the changes in an appropriate sequence to 
> reduce annoyances to a minimum!
Ah nice!
> 
>>>
>>> Opinions?
>> I will test VectorGrahics tomorrow, with a clean image
>> and try to do some measurements. Until then I am undecided.
> 
> That would be _really_ helpful.
Sorry for being late with this, I caught a flue,
currently I am living from throat lozenges.

I suggest the following plan:

I still have to bug reports with fixes lingering around
here, I will send them first.

Then I will try to hunt down that memory leak.
Preliminary information on this issue:
This is the ls-output of two images with essentially
the same code. One of them I saved after I terminated an
non-terminating recursion with «Alt-.»:

-- snip --
bear at speedy ~/s/c/Environments> ls -lh Haver6.0-5494-peggy2.image 
Haver6.0-5494-peggy3.image
-rw-rw-r-- 1 bear bear 678M Okt 18 14:58 Haver6.0-5494-peggy2.image
-rw-rw-r-- 1 bear bear  38M Okt 19 14:08 Haver6.0-5494-peggy3.image
-- snip --


When I can reproduce this, I will start
to time and profile WorldMorph::#restoreDisplay
in Haver and in Cuis with and without vector graphics.

Is that a viable plan?

> 
> Thanks,
> 

HTH and Best Regards,

Gerald