[Cuis-dev] VectorGrahicsPlugin Troubles (WAS: Re: A few tweaks to preferences)

[Gerald Klix]

On 8/21/21 8:07 PM, Juan Vuletich via Cuis-dev wrote:
> On 8/21/2021 2:41 PM, Gerald Klix via Cuis-dev wrote:
>>
>>
>> On 8/21/21 7:20 PM, Juan Vuletich via Cuis-dev wrote:
>>> On 8/21/2021 7:53 AM, Gerald Klix wrote:
>>>> Hi guys,
>>>>
>>>> see below please.
>>>>
>>>> On 8/21/21 4:56 AM, Phil B via Cuis-dev wrote:
>>>>> Juan,
>>>>>
>>>>> On Fri, Aug 20, 2021 at 10:34 PM Juan Vuletich via Cuis-dev <
>>>>> cuis-dev at lists.cuis.st> wrote:
>>>>>
>>>>>> Thanks Gerald. I have experienced occasional crashes when zooming 
>>>>>> heavy
>>>>>> windows, but this surely makes it more likely to happen. I can't 
>>>>>> test it
>>>>>> right now (I need Windows or Linux), 
>>>> No, you don't, this package works with the simulated
>>>> key-press-generated mouse-scroll-events, too.
>>>
>>> You are right. Check the attaches, that I needed to make it work on 
>>> Mac (in Mac, ctrl + scroll controls the OS zoomin facility, and Cuis 
>>> won't get those events).
>> IC. I did not know about that rawMacOptionKeyPressed stuff, we should
>> abstract that away, before this dease spreads through the image ;=].
> 
> Well, in regular PCs don't have an option key, instead they have the 
> "Windows" key, and Linux and Windows VMs don't report it. That's why it 
> is named in a clearly platform specific way in Cuis.
> 
> Suggestions welcome!
I am undecided.
This mouse-scroll adventure started, because I wanted
these Windows, Menu and AltGr-keys (and all the mouse buttons)
reported by the VM at least under Linux.
I think I can get it working with Windows, too.
If we do that, we will introduce about an incompatibility with
Squeak. As I said in another post:
Til now I could resist the temptation to tweak the VM.

I will think about that, this will take some time.

> 
>>
>> The Core changes stuff is a superset of the exercise left to the
>> gentle reader ;-}
>>>
>>>>>> but I thought of a possible reason
>>>>>> for the problem. If many drag-the-scale-handle events are 
>>>>>> processed in
>>>>>> the same Morphic cycle, and processing each takes too much time, next
>>>>>> cycle will take longer, so it will process even more of those 
>>>>>> events (if
>>>>>> generated at a constant rate by an insisting user). The growth is
>>>>>> exponential, with no bound. So this is guaranteed to end badly!
>>>>>>
>>>>>
>>>>> Yes, this can be an issue with non-VG Morphic too if one isn't 
>>>>> careful.
>>>>> I've run into it with everything from scrolling to mouse moves to 
>>>>> dragging
>>>>> etc.  VG likely just makes it a more frequent issue given the 
>>>>> overhead of
>>>>> the increased drawing time per frame
>>>>>
>>>>>
>>>>>>
>>>>>> I just pushed an update that limits the processing of 
>>>>>> MouseMoveEvents to
>>>>>> just one per cycle. The other kinds of events are much less likely to
>>>>>> cause this kind of problems (although not completely impossible), and
>>>>>> are (as usual) processed until the event queue is empty.
>>>> Thanks your change now prevents SegFaults. I tested with Haver and 
>>>> Cuis.
>>>
>>> Nice.
>> Ah, well, see my latest post. I suppose it's time for another VM build
>> with latest vmmaker and plugin. This time I wont strip it.
>>>
>>>>>>
>>>>>
>>>>> Please don't discard events like this.  It will have an impact on
>>>>> sensitivity/resolution which is already not great.  Can we do some
>>>>> combination of coalescing and/or more selectively discarding them 
>>>>> instead?
>>>> It certainly feels a good deal more sluggish now, Cuis, with it's
>>>> nice background bitmap, more than Haver. If you use a true-type font
>>>> instead of the standard bitmap font, Haver is faster when zooming
>>>> windows, moving windows however is slower (big surprise, that :).
>>
>> I suppose it would make sense to automatically suppress window display
>> when it takes too long during a move,
>> like Preferences class>>#cheapWindowReframe but a bit smarter.
I looked at the reframing code, it already has some hard-coded
timeouts for switching to a simpler and faster resize hinting.
>>
>> Apropos "reframe': If you scale a SystemWindow, and change it's size
>> by DND the outline rectangle is not scaled.
> 
> Yes. Something like that would be especially good on slow hardware.
> 
>>
>>
>> Best Regards,
>>
>> Gerald
> 
> Thanks,
>