[Cuis-dev] Morph redrawNeeded

Wed May 3 13:36:40 PDT 2023

Note that I'm not using stepping in my real example. The redrawNeeded is
essentially called from #mouseMove:localPosition: in the morph.

If I take out the call to #redrawNeeded from the mouse move handler method,
and instead print Time millisecondClockValue to the Transcript, I'm seeing
an average of about 15ms between each mouse move event, which is plenty
fast.

- Jon

On Wed, 3 May 2023 at 16:22, Juan Vuletich <juan at cuis.st> wrote:

> Hi Jon,
>
> Your example made me realize that between the #redrawNeeded and the actual
> redraw we'd not wait for the inter cycle pause. I just pushed an update for
> this. It will make your measurements go to essentially zero, although it
> won't improve the FPS.
>
> What is needed is to understand where is that gap time spent. Is it spent
> on the inter cycle pause? Does the situation improve is you set a smaller
> #stepTime? If you want 60fps, your #stepTime should be below 17ms for sure.
> But still you'll not reach the fps if the cpu is busy doing something else.
> We need to understand what this is.
>
> On 5/3/2023 5:09 PM, Jon Hylands via Cuis-dev wrote:
>
> As an aside, I do not see the double-call to drawOn: in the real code -
> the morph that does all the drawing is already a subclass of BoxedMorph.
>
> With my timing code inserted, it takes (on my desktop) about 14.8ms on
> average to draw the entire morph. However, while I'll dragging my mouse
> over the morph to scroll it (with the mouse button down), I'm seeing the
> following gap times between calling #redrawNeeded and the subsequent call
> to #drawOn:
>
> 62 62 62 61 64 63 64 64 62 62 62 64 64 61 64 70 61 64 63 64 64 64 64 62 62
> 62 64 64 64 63
>
> That's pretty consistent - anywhere from 61 to 70ms.
>
> I don't need to make my draw code faster, I need to get rid of that gap
> time. My FPS would go from about 12 to about 60 if that call happened
> immediately with no delay.
>
> - Jon
>
>
> On Wed, 3 May 2023 at 15:56, Jon Hylands <jhylands at gmail.com> wrote:
>
>> Hey Juan,
>>
>> I'm going to have to do some more looking. Like I said before, the draw
>> code only takes about 30-40ms on the rpi, and that is while I'm moving my
>> finger on the touch screen (or using a mouse to drag). I'm still only
>> seeing #drawOn: called every 300ms or so in that case (while moving the
>> mouse).
>>
>> I'll see if I can get a simpler example going on the pi.
>>
>> - Jon
>>
>>
>> On Wed, 3 May 2023 at 15:45, Juan Vuletich <juan at cuis.st> wrote:
>>
>>> Hi Jon,
>>>
>>> On 5/3/2023 4:01 PM, Jon Hylands via Cuis-dev wrote:
>>> > Hey Juan,
>>> >
>>> > Try the attached in a virgin image. There is definitely something
>>> > weird going on - #drawOn: is getting called twice when #redrawNeeded
>>> > is sent. Make sure the Transcript is open.
>>> >
>>> > - Jon
>>>
>>> This is good. It lets us talk about concrete stuff.
>>>
>>> #drawOn: is called twice. You can print the class of the canvas
>>> argument. It is called once on a BoundsFinderCanvas, and another on a
>>> VectorCanvas. This Morph is a subclass of PlacedMorph, meaning that it
>>> has all the VectorGraphics generality available, with some possible
>>> performance cost. I'll come back to this later.
>>>
>>> Now, if I remove the clearing of the startTime variable at the end of
>>> #drawOn:, open an instance, and close all windows (including the
>>> Transcript), I see values around 150mS. But, if I move my mouse quickly
>>> to generate _many_ mouse move events, the times it displays are 0 or 2
>>> (on a rather fast laptop). It is because Morphic sleeps a bit if there's
>>> nothing to do. This is essentially to avoid wasting CPU, energy, etc.
>>> See use of ivar 'pause' in WorldMorph. On the Raspi, 10 to 20 fps should
>>> be possible.
>>>
>>> As I said above, this Morph can be made more efficient. Morphic in Cuis
>>> lets you do stuff like Sample01Star. Check it. It doesn't say what are
>>> its 'bounds', what pixels are inside it, etc. It only knows how to draw
>>> itself and it just works. It is the framework who takes the trouble to
>>> find out all the details. But his generality has some cost. For
>>> instance, the need for a BoundsFinderCanvas, and the need to call
>>> #drawOn: twice: the first call is to find the current bounds of the
>>> morph.
>>>
>>> But as your example doesn't really need all this, but we want good
>>> performance on a slow cpu, we can use a more limited style and features,
>>> that is enough for simple boxes and text (Browsers and other Smalltalk
>>> tools, SystemWindows, PluggableMorphs all work like this) :
>>> - Copy the class as #RedrawNeededTest2
>>> - Change superclass to BoxedMorph
>>> - Add this method:
>>> initialize
>>>      super initialize.
>>>      extent := `500 at 500`.
>>>      color := Color black.
>>>      borderColor := Color white.
>>>      borderWidth := 1.
>>> - Make #drawOn: call super drawOn: aCanvas. Remove the call to draw and
>>> fix the box.
>>> Doing something similar could make a visible difference in your actual
>>> application. Or not. Not sure.
>>>
>>> Hope this helps,
>>>
>>> --
>>> Juan Vuletich
>>> cuis.st
>>> github.com/jvuletich
>>> researchgate.net/profile/Juan-Vuletich
>>> independent.academia.edu/JuanVuletich
>>> patents.justia.com/inventor/juan-manuel-vuletich
>>> linkedin.com/in/juan-vuletich-75611b3
>>> twitter.com/JuanVuletich
>>>
>>>
>
> --
> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230503/4c344e34/attachment.htm>