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

[Juan Vuletich]

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!

>
> 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.

Yes. Something like that would be especially good on slow hardware.

>
>
> Best Regards,
>
> Gerald

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich