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

[Gerald Klix]

Dave,

please look below.

On 8/21/21 8:10 PM, David T. Lewis via Cuis-dev wrote:
> On Sat, Aug 21, 2021 at 02:54:52PM -0300, Juan Vuletich via Cuis-dev wrote:
>> 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 watching for updates :-)
> 
> One suggestion - consider adding some kind of #primitivePluginVersion
> to VectorEnginePlugin, possibly just answering an integer. If the
> VectorGraphics version requires a compatible plugin version, you
> can test for it in advance from the image.
I can remember that I asked that question, too. I was pointed to:
VectorEngineWithPlugin>>#pluginApiVersion

--- snip ---
pluginApiVersion
	"
	VectorEngineWithPlugin isPluginAvailable
	Semantic version numbering in a single SmallInteger:
	Version numbers 1 to 99 are backwards compatible. When incompatibility 
is needed. jump straight to 101.
	Version numbers 101 to 199 are backwards compatible. When 
incompatibility is needed. jump straight to 201.
	And so.
	Note: this is Api version, not package version. If no Api change, Api 
version doesn't change, regardless of changes in the Plugin or Smalltalk 
code.
	See senders and implementors.
	"
	<primitive: 'pluginApiVersion' module: 'VectorEnginePlugin'>

	^ 0
--- snap ---
The clever semantic version scheme is not used, yet.>
> Dave
> 
> 
>> 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
>>
>> -- 
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev