graphics performance

[Dave Dyer]

Not exactly a complaint, but I'm a little disappointed by the performance of graphics on mobiles. For

example, my most demanding screen renders on my PC in 12 us, but the same frame on my ipad

takes 200 us.  Even adjusting for the number of pixels in the frame, that's still a factor of 7 slower.

I've done a little metering, and don't see any obvious lumps or issues, just that pushing

bits into a framebuffer (mostly from other images) is a lot slower than I wish it was.

[Shai Almog]

As far as I recall you use double/triple buffering to render. These are policies that are painfully slow on mobile devices.

Mobile devices need to render directly and are heavily optimized to that as the rendering hardware acceleration doesn't work for in-memory raster.

[Dave Dyer]

This is only for rendering the main frame, not the buffering costs which are incurred elsewhere.  But this rendering is to an offscreen

buffer rather than where ever the direct paint would go.  I'd be happy to paint directly if that was visually acceptable.

[Steve Hannah]

Underneath the covers, iOS has a completely different graphics implementation than desktop, so it's possible that some graphics operation you are performing is "slow" on the iOS stack.  Even just comparing graphics rendering of mutable images vs to the screen on the same platform, there may be very different implementations under the hood.  On iOS, especially this is the case as the graphics implementation of mutable images shares very little with the implementation to screen; the latter using OpenGL - and soon Metal.  In the past, iOS was known to have slow mutable images - i'm not sure to what extent, if any, this is still the case.

There is a method Display.areMutableImagesFast() which returns false on iOS and true elsewhere.  This is used in various parts of our codebase where we may consider rendering to an image for performance reasons (e.g. during transitions) - we use this flag to decide not to render to an image buffer in such cases.

On Wed, Apr 8, 2020 at 4:44 AM Dave Dyer <daved...@gmail.com> wrote:

This is only for rendering the main frame, not the buffering costs which are incurred elsewhere.  But this rendering is to an offscreen

buffer rather than where ever the direct paint would go.  I'd be happy to paint directly if that was visually acceptable.

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/7aac6293-9c92-4e46-ba7c-cb78efc62a9c%40googlegroups.com.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Dave Dyer]

Qualitatively speaking, these numbers aren't out of line with with what I would expect

based on my assessment of raw cpu speed as delivered by codename1.  That is, with

all the ineffeciencies of the code you generate taken as given.  I'm not complaining,

but the cpu speed of my ipad is 6% of what I get on my trusty old desktop.

I get similar results on android devices.

The main contributing factor on the ipad is the much larger number of pixels being

pushed as a consequence of the retina display.  It's disappointing to have to resort

to clever programming to get performance, rather than letting the raw speed of the

device do the work :)

[Shai Almog]

These devices aren't very fast. ARM is still much slower than Intel. The reason the devices feel fast is the GPU. This is true for iOS and Android.

If you're drawing to an image you're effectively disabling any form of native drawing optimization.

Actually, the default functionality we have with our component framework works perfectly fine. So would drawing normally by overriding paint. All of these are standard.

What you're doing is the clever programming by using double buffering. Removing that stuff will boost your performance significantly and also let you use the native debugging tools to see your inefficiencies. E.g. Android developer tools have pretty amazing performance tracking tools.

[Dave Dyer]

Agreed on all fronts.  But I wish that when I call Image.getGraphics(), the image would be

converted to a representation where the GPU would be used for drawing to it, or some

equivalent software solution that would have a special subclass of images that were

designated in advance to be GPU resident.

[Shai Almog]

This is how the native OS is implemented. Both Android and iOS use a software renderer when painting off-screen. As such we don't have access to hardware acceleration when drawing there.

The GPU just isn't available for that purpose. This was especially painful for us on Android where until Android 3 the best practice was double buffering and all our code relied on that. We had to do a complete overhaul of our rendering pipeline to support their newer approach.