Porting libmypaint to android

[jeekun]

Hi.

Libmypaint is a real great library.

I'm seeking to port libmypaint to Android, using openGL ES to do the rendering.
I’ve made a sample, here

But when I change to some brushes, such as "brushes/deevad/basic_digital_knife.myb", it not so efficient.
You can see that by selecting "Brush2" and drawing in the sample.
And I've check the painting time by "mypaint_brush_get_total_stroke_painting_time", sometimes it is rare long.

So counld you please give me some suggestion about how to optimize it?

Thank you !

[achadwick]

Sounds like a neat project, but I can't help much right now. Looks like a native build for each of the Android platforms, so you're asking me how to get the code tweaked for many things. Your question is many questions 😄

Without a good way of seeing the source code changes you've made, we cannot advise. All you've shown me is an APK, which I have no way of running since I don't do Android.

Some brushes are slow because they involve lots of writes, lots of reads, or both. What brushes do you find fast, and what brushes do you find slow?

How are you intending to keep your port up to date with API changes here? How much can be changed, and how willing are you to get involved with libmypaint's C development?

[jeekun]

Thanks for the reply!

The work I have done so for is just writing a jni wrapper class for the libmypaint and suiting it in android, then I found some brushes are slow.

Yeah, I guess it's too heavy for the phone's cpu on some brush, such as "basic_digital_knife.myb".
So my main question is that is there a way to avoid some unimportant calculation and we can still get a familiar result. Then I can change it more effective.

I haven't deep into the libmypaint's algorithm so far, so maybe my question is too brusque... sorry for that.

[ghost]

I do not think that the question is brusque. I think that nobody would mind any speed improvement, including to the brush situation. I guess one problem may be how to test it on android if the main dev(s) do not use or have access to android (I don't have either by the way; I have no idea how the speed is there on android but I understand that it can not compete with even cheap modern desktop systems today).

I guess in theory one could perhaps use generic, simpler fallback brushes? Can you perhaps compile some list as to which brushes are the biggest offenders (since you wrote that only some brushes are slow ... so perhaps it may eventually lead up to a general improvement there).