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

[Juan Vuletich]

Thanks Gerald!

Luckily, in this case, the crash.dmp pointed straight to a clear bug in 
the code. In most other cases, any primitive that modifies an array also 
gets the array as argument (even if passed before). This is in case the 
GC moves it around. But when I added contour, somehow I forgot about 
this. #primResetContourTop:bottom: doesn't pass the contour array as 
argument, and therefore could produce an invalid access after GC.

This will require changes to the plugin and new VMs.

I'll be working on this in the next few days. Please stay tuned.

Thanks,

On 8/21/2021 2:24 PM, Gerald Klix via Cuis-dev wrote:
> Alas I had another SegFault, that happened after a 2h pause
> after testing your changes, I wanted to change the screen size
> in Haver (with no background image).
>
> I attached the crash.dmp-file. It is probably not that helpful,
> I stripped the VM and its plugins.
>
>
> HTH,
>
> Gerald
>
>
>
> On 8/21/21 7:18 PM, Juan Vuletich via Cuis-dev wrote:
>> On 8/20/2021 11:56 PM, 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 <mailto: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), 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.
>>>
>>>
>>> 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?
>>
>> The point is to improve sensitivity to user actions. Slowing down the 
>> Morphic cycle, reducing fps, to process events that won't give 
>> feedback to the user until the next cycle is what makes it worse. The 
>> way to improve is to give the user feedback as quickly as possible.
>>
>>>
>>>
>>>     Please try again with this updates if you have the chance. It may
>>>     help.
>>>
>>>     Thanks,
>>>
>>>     --     Juan Vuletich
>>>     www.cuis-smalltalk.org <http://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
>>>
>>>
>>> Thanks,
>>> Phil
>>
>>
>>


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