"Kivy isn't fast enough"

[Candide]

In his keynote at Pycon2014, Guido taked about Kivy and reported that mobile developpment team at DropBox doesn't use Kivy for being too slow, cf. https://www.youtube.com/watch?v=0Ef9GudbxXY#t=760

Kivy not fast enough? It this True ? Kivy graphics features are written at the C level in Cython, aren't they ?

[Alexander Taylor]

Kivy is very fast and efficient for a lot of things - in terms of basic graphics operations you can easily push and manipulate thousands of vertices with complex effects at no perceptible slowdown. Other things are not so fast, but still not generally a problem - the widget system gives a lot of power but the event management behind the scenes can be a problem if relying on it for very complex things (e.g. hundreds of widgets moving around individually). I don't think this is what Guido is referring to though, it's not a problem for most kind of apps, mainly if abusing widgets for use in games - in which case the solution is to use graphics instructions more directly.

I guess the real perceptible problem comes from a couple of other things. One is that some of our widgets have been inefficient and slow at points in the past (though some are drastically better now), and don't necessarily represent what is really possible. Another possible contributor is that our android bootstrap can be slow - there's a necessary pause (with loading screen) when the app is started, in which the python interpreter gets going and for the display is initialised. It's easy to make this pause quite long by accident (putting a lot of code in bad places), though it's not possible to remove completely even if you don't do this. This may be improved by some ongoing stuff people have been trying, including reducing our package sizes, changing how we access the apk contents, and maybe switching to a new sdl2 provider.

So overall, I don't know exactly what Guido was referring to, but there are a few candidate things that could well contribute to the conclusion. Probably none are fundamental problems (most certainly aren't), but they may require some less obvious techniques that are perhaps less well documented to work around.

[Ao Yen]

Aside from kivy what other options are there for Android development using Python.

[João Ventura]

Hi there,

I've done a prototype of an application of mine in Kivy. It was fast to develop, but slow to run. Other problem that I had was lack of antialiasing and general lack of polishing. I've considered the Python backend with a native Android frontend, and did a tutorial series on that: http://techventura.wordpress.com/2014/04/21/embedding-python-in-android-series/


João Ventura

[Kovak]

Just wanted to note here: Kivy does have anti-aliasing, however it depends on your hardware for how this was implemented. It is of course always possible to implement your own anti-aliasing in shader, although depending on which opengl versions you are targeting your options here are somewhat limited.

[Sergey Cheparev]

Which hardware/software supports anti-aliasing in kivy for sure? 

I have samsung s4 with last cm11 M8 and I don't get it. On what does it depend? The biggest problem for me is that I must use graphic instructions and not widgets or images to speed up my app, but everything I try to paint with it is just ugly.

среда, 9 июля 2014 г., 2:40:30 UTC+2 пользователь Kovak написал:

[Alexander Taylor]

Probably just about anything should support the FXAA shader in
effectwidget, though this may not be a very good implementation.
I'm not sure about hardware antialiasing.

You mention the instruction/widget distinction, but bear in mind all
widgets are implemented directly via canvas instructions. They generally
achieve their acceptably aliased edges by displaying images with (where
relevant) blurred boundaries - have you tried this?

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Kivy users support" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kivy-users/dCRkQHLg2Oc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> kivy-users+...@googlegroups.com
> <mailto:kivy-users+...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Sergey Cheparev]

Do you mean I have to "build-in" the anti-aliasing in the image
itself? I was thinking about it (and I'm going to try it someday :)),
but I have many of Ellipses/Circles in my app and I can't use this
technique to "mock" the anti-aliasing, like with buttons/images.

Or maybe do you mean something different?

> kivy-users+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>

--
<http://stackoverflow.com/users/1205242/eviltnan>
<http://www.youtube.com/user/easygoingshow>
<http://www.youtube.com/user/migrantyproject> <http://cheparev.com>
<https://play.google.com/store/apps/details?id=org.kognitivo.kognitivo>

[Alexander Taylor]

That's what I meant, yes.

It would be possible to automate this to various extents within kivy
itself, though not without drawbacks. It is an area of activity at the
moment.

[Sergey Cheparev]

You mean something like utility to create this kind of 'borders' for
already existing images? Permanent or in runtime?

[Alexander Taylor]

You could do this with the right shaders and vertex instruction
structure, or (for plain colours) with the right pregenerated texture.
For instance, see the SmoothLine vertex instruction; a similar thing
would be possible for other shapes.

[Sergey Cheparev]

Cool! thanks! I'll try it in kognitivo :)

   

[Kovak]

Inside the Kivy config there is an undocumented multisamples attribute. This sets MSAA for your Window, I believe it defaults to 2x, here is a difference in a red circle drawn at 16x and 0:

http://kivent.org/images/aa.png

>>>>> <mailto:kivy-users+unsub...@googlegroups.com>.

>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "Kivy users support" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/kivy-users/dCRkQHLg2Oc/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> kivy-users+...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Kivy users support" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/kivy-users/dCRkQHLg2Oc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> kivy-users+...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

--
You received this message because you are subscribed to a topic in the Google Groups "Kivy users support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kivy-users/dCRkQHLg2Oc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kivy-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sergey Cheparev]

Does it work on all platforms? I've tried it on linux and can't see any difference (this option is in section graphics). And also I'd like to know why is this option set to 2 by default.

четверг, 10 июля 2014 г., 21:00:36 UTC+2 пользователь Kovak написал:

[Alexander Taylor]

It's hardware dependent. Desktops will normally support higher (depending on gpu and drivers), like kovak's 16x example. Low powered devices, including many mobiles, will not support a high multisampling (if any at all).

I think this is mostly because it's quite computationally intensive (it corresponds to literally rendering a multiple of the normal pixel number then downscaling that). This is probably part of why we use 2 by default, along with that it probably makes other things (like text) look worse instead of better.

[Damien Moore]

On Friday, July 11, 2014 6:52:14 AM UTC-4, Alexander Taylor wrote:

It's hardware dependent. Desktops will normally support higher (depending on gpu and drivers), like kovak's 16x example. Low powered devices, including many mobiles, will not support a high multisampling (if any at all).

I think this is mostly because it's quite computationally intensive (it corresponds to literally rendering a multiple of the normal pixel number then downscaling that). This is probably part of why we use 2 by default, along with that it probably makes other things (like text) look worse instead of better.

So I gather that the alternatives are (1) pre-generate anti-aliased sprites/shapes in something like inkscape and deploy multiple sized PNGs, (2) find a good SVG rendering library to generate static AA'd visuals for run-time use or (3) use a library that will pre-generate AA'd shapes at start-up for run-time use. Does anyone know of a good, small lib that will do (2) or (3) and run on android as well as PC? I like the idea of not having to keep a bunch of pre-rendered PNGs around.

[Sergey Cheparev]

On current master SmoothLine draws nothing

четверг, 10 июля 2014 г., 15:44:23 UTC+2 пользователь Alexander Taylor написал:

>>>>> <mailto:kivy-users+unsub...@googlegroups.com>.

[Tanay Chowdhury]

Alexander Taylor  kivy.uix.filechooser is fast enough in desktop but very slow in android,even in S6 and swipes are unresponsive as well. Do we have any solution around.As I feel an all python app built in such way will not be appreciated by users for its slowness.

[Alexander Taylor]

The FileChooser is architecturally poor. It's due a rewrite, probably
using RecycleView, but nobody has had time for that yet.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Kivy users support" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kivy-users/dCRkQHLg2Oc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> kivy-users+...@googlegroups.com

> <mailto:kivy-users+...@googlegroups.com>.