[Cuis-dev] Morph redrawNeeded

[Jon Hylands]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230503/be764f97/attachment.htm>