[Cuis-dev] Morph redrawNeeded
Juan Vuletich
juan at cuis.st
Wed May 3 13:22:33 PDT 2023
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
> <mailto: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
> <mailto: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 <http://cuis.st>
> github.com/jvuletich <http://github.com/jvuletich>
> researchgate.net/profile/Juan-Vuletich
> <http://researchgate.net/profile/Juan-Vuletich>
> independent.academia.edu/JuanVuletich
> <http://independent.academia.edu/JuanVuletich>
> patents.justia.com/inventor/juan-manuel-vuletich
> <http://patents.justia.com/inventor/juan-manuel-vuletich>
> linkedin.com/in/juan-vuletich-75611b3
> <http://linkedin.com/in/juan-vuletich-75611b3>
> twitter.com/JuanVuletich <http://twitter.com/JuanVuletich>
>
--
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/48fde5b0/attachment-0001.htm>
More information about the Cuis-dev
mailing list