<div dir="ltr">Note that I'm not using stepping in my real example. The redrawNeeded is essentially called from #mouseMove:localPosition: in the morph.<div><br></div><div>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.</div><div><br></div><div>- Jon</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 May 2023 at 16:22, Juan Vuletich <<a href="mailto:juan@cuis.st">juan@cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div bgcolor="#ffffff">
Hi Jon,<br>
<br>
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.<br>
<br>
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.<br>
<br>
On 5/3/2023 5:09 PM, Jon Hylands via Cuis-dev wrote:
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>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<br>
</div>
<div><br>
</div>
<div>That's pretty consistent - anywhere from 61 to 70ms.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Jon</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 3 May 2023 at 15:56,
Jon Hylands <<a href="mailto:jhylands@gmail.com" target="_blank">jhylands@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hey Juan,
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>I'll see if I can get a simpler example going on the
pi.</div>
<div><br>
</div>
<div>- Jon</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 3 May 2023 at
15:45, Juan Vuletich <<a href="mailto:juan@cuis.st" target="_blank">juan@cuis.st</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jon,<br>
<br>
On 5/3/2023 4:01 PM, Jon Hylands via Cuis-dev wrote:<br>
> Hey Juan,<br>
><br>
> Try the attached in a virgin image. There is
definitely something <br>
> weird going on - #drawOn: is getting called twice
when #redrawNeeded <br>
> is sent. Make sure the Transcript is open.<br>
><br>
> - Jon<br>
<br>
This is good. It lets us talk about concrete stuff.<br>
<br>
#drawOn: is called twice. You can print the class of the
canvas <br>
argument. It is called once on a BoundsFinderCanvas, and
another on a <br>
VectorCanvas. This Morph is a subclass of PlacedMorph,
meaning that it <br>
has all the VectorGraphics generality available, with some
possible <br>
performance cost. I'll come back to this later.<br>
<br>
Now, if I remove the clearing of the startTime variable at
the end of <br>
#drawOn:, open an instance, and close all windows
(including the <br>
Transcript), I see values around 150mS. But, if I move my
mouse quickly <br>
to generate _many_ mouse move events, the times it
displays are 0 or 2 <br>
(on a rather fast laptop). It is because Morphic sleeps a
bit if there's <br>
nothing to do. This is essentially to avoid wasting CPU,
energy, etc. <br>
See use of ivar 'pause' in WorldMorph. On the Raspi, 10 to
20 fps should <br>
be possible.<br>
<br>
As I said above, this Morph can be made more efficient.
Morphic in Cuis <br>
lets you do stuff like Sample01Star. Check it. It doesn't
say what are <br>
its 'bounds', what pixels are inside it, etc. It only
knows how to draw <br>
itself and it just works. It is the framework who takes
the trouble to <br>
find out all the details. But his generality has some
cost. For <br>
instance, the need for a BoundsFinderCanvas, and the need
to call <br>
#drawOn: twice: the first call is to find the current
bounds of the morph.<br>
<br>
But as your example doesn't really need all this, but we
want good <br>
performance on a slow cpu, we can use a more limited style
and features, <br>
that is enough for simple boxes and text (Browsers and
other Smalltalk <br>
tools, SystemWindows, PluggableMorphs all work like this)
:<br>
- Copy the class as #RedrawNeededTest2<br>
- Change superclass to BoxedMorph<br>
- Add this method:<br>
initialize<br>
super initialize.<br>
extent := `500@500`.<br>
color := Color black.<br>
borderColor := Color white.<br>
borderWidth := 1.<br>
- Make #drawOn: call super drawOn: aCanvas. Remove the
call to draw and <br>
fix the box.<br>
Doing something similar could make a visible difference in
your actual <br>
application. Or not. Not sure.<br>
<br>
Hope this helps,<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://cuis.st" rel="noreferrer" target="_blank">cuis.st</a><br>
<a href="http://github.com/jvuletich" rel="noreferrer" target="_blank">github.com/jvuletich</a><br>
<a href="http://researchgate.net/profile/Juan-Vuletich" rel="noreferrer" target="_blank">researchgate.net/profile/Juan-Vuletich</a><br>
<a href="http://independent.academia.edu/JuanVuletich" rel="noreferrer" target="_blank">independent.academia.edu/JuanVuletich</a><br>
<a href="http://patents.justia.com/inventor/juan-manuel-vuletich" rel="noreferrer" target="_blank">patents.justia.com/inventor/juan-manuel-vuletich</a><br>
<a href="http://linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">linkedin.com/in/juan-vuletich-75611b3</a><br>
<a href="http://twitter.com/JuanVuletich" rel="noreferrer" target="_blank">twitter.com/JuanVuletich</a><br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
Juan Vuletich
<a href="http://cuis.st" target="_blank">cuis.st</a>
<a href="http://github.com/jvuletich" target="_blank">github.com/jvuletich</a>
<a href="http://researchgate.net/profile/Juan-Vuletich" target="_blank">researchgate.net/profile/Juan-Vuletich</a>
<a href="http://independent.academia.edu/JuanVuletich" target="_blank">independent.academia.edu/JuanVuletich</a>
<a href="http://patents.justia.com/inventor/juan-manuel-vuletich" target="_blank">patents.justia.com/inventor/juan-manuel-vuletich</a>
<a href="http://linkedin.com/in/juan-vuletich-75611b3" target="_blank">linkedin.com/in/juan-vuletich-75611b3</a>
<a href="http://twitter.com/JuanVuletich" target="_blank">twitter.com/JuanVuletich</a></pre>
</div>
</blockquote></div>