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

[Gerald Klix]

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 ;=].

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.

Apropos "reframe': If you scale a SystemWindow, and change it's size
by DND the outline rectangle is not scaled.


Best Regards,

Gerald