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

Juan Vuletich juan at jvuletich.org
Mon Aug 23 18:03:59 PDT 2021


Hi Gerald,

I pushed an update to the plugin yesterday, and this is a good time to 
rebuild VMs.

Thanks!!!

Cheers,

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


On 8/21/2021 3:27 PM, Gerald Klix via Cuis-dev wrote:
>
>
> On 8/21/21 7:54 PM, Juan Vuletich via Cuis-dev wrote:
>> Thanks Gerald!
>>
>> Luckily, in this case, the crash.dmp pointed straight to a clear bug 
>> in the code. 
> That's a big relief! I feared that this spurious crashes
> would lead to a tedious sequence/tree of trials and errors,
> sending E-Mails back and forth.
>> 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.I am 
>> still hopeful that I can withstand the temptation to start
> VM development ... Thanks for the information.
>>
>> This will require changes to the plugin and new VMs.
> Of course. Just send me a message than I will rebuild the VMs.
>>
>> I'll be working on this in the next few days. Please stay tuned.
> While you are at it, any chance to get 
> VectorDrawingCanvas>>image:multipliedBy:at:
> implemented or should I wait until we have a proper
> vector icon set?
> Background information: Menus and my nice PlugableButtonMorphs
> do not scale anymore, because they have icons implemented as Forms.
>
> As a workaround is there a chance to force some morphs
> to be drawn by a BitBlit canvas, doing the transformations
> as image scaling (The ugly old Squeak way)?
>
>
> Best Regards,
>
> Gerald
>
>>
>> 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
>>>>
>>>>
>>>>
>>
>>




More information about the Cuis-dev mailing list