[Cuis-dev] Morph redrawNeeded

[Jon Hylands]

Hi Juan,

I think you missed the point I was trying to make. The drawing code is very
fast - it would run at 70+ fps if I was calling the draw code directly as
fast as it can go.

The issue is the delay between sending #redrawNeeded and the system sending
#drawOn:. On my desktop, that delay is around 50ms. On the rpi4, that delay
is around 250-300ms. It doesn't matter how fast the draw code is if the
fastest you can call the drawOn: is 3-4 times per second.

I don't know if there is something in my image that is messed up, but I
don't think so - the image on the rpi was a virgin image that I loaded my
package into (plus all the dependent packages that get loaded
automatically).

There are no extra processes running in the background.

- Jon


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

> On 5/2/2023 5:42 PM, Jon Hylands via Cuis-dev wrote:
> >
> > Hi everyone,
> >
> > I'm doing some GUI work on a Raspberry pi 4 that has a 1080p HDMI LCD
> > screen (in portrait mode).
> >
> > I have a special morph, which displays a list of nearby airports,
> > sorted by distance from the user's gps location. The morph can show 9
> > airports at a time, and you can smoothly scroll the list (which has a
> > couple hundred entries in total).
> >
> > ...
> >
> > On my desktop, it takes about 14ms to draw the 9 entries, and I get
> > about 11 frames per second scrolling. The scroll code is implemented
> > in a method called from #mouseMove:localPosition:, and it simply does
> > some math, sets the scrollPosition variable, and calls #redrawNeeded.
> >
> > On the rpi4, it takes about 50ms to draw the list, and it averages 2.5
> > frames per second, which is terrible.
> >
> > On my desktop, it appears that there is a fairly large gap (50ms)
> > between the time #redrawNeeded is sent, and the corresponding call to
> > #drawOn: is sent. This explains the poor performance pretty much in
> > total. What can I do to make that happen faster?
> >
> > - Jon
> >
>
> Hi Jon,
>
> It really looks like it could be way faster, both on the Raspi and your
> Desktop. The first thing that comes to mind is that text rendering is
> much slower if there's scaling or rotation. So, the first advice is to
> be sure that all the morphs involved in the list, up to world, don't do
> rotation or scaling (their locations should only be integer
> translations). If needed, use a different font size.
>
> Yep. If I zoom in your screenshot, I can see that the letters 'o' in
> 'London' have subpixels rendered differently. This is geometrically
> correct, but it shows that it is not caching font glyphs, but drawing
> the TrueType Beziers each time. Caching is only done if there's no zoom
> or rotation, and it really speeds up text rendering.
>
> If the above doesn't help, I'd like to be able to reproduce the
> behavior, so I can understand in detail. I have a Raspi 3B I can use for
> testing. If the issue persists, please prepare an image, or some
> instructions to load the code, so I can try.
>
> Thanks,
>
> --
> 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/21296610/attachment.htm>