Tile instances should manage their own state.

[p-lr]

Consider using an ObjectAnimator for alpha animation. To keep using hardware acceleration, see this. Another article explains how constant invalidating a view (which uses an hardware layer) hurts performance.

[moagrius]

Tile instances should manage their own threading and state

+1 on having Tiles control more of their own state, but I'm hesitant about moving Threading logic to the Tile instance because we don't want a 1:1 tile-to-thread - I've spent a lot of time deep in threading recently and have a couple strategies to try; that said, both would have thread management outside of the Tile definition.

Consider using an ObjectAnimator for alpha animation.

-1 i'm fairly confident it's much more performant to do it in onDraw like we're doing. FWIW earlier versions did use Animators - but imagine - each one needs it's own timers and cycle management, probably Handlers and posting runnables, etc - in order to support animation on any surface, from any source - we know our animation is just going to happen in the onDraw we're doing anyway, and we only need to compute time at draw-time, etc.

To keep using hardware acceleration, see this.

Not clear on the suggestion here...?

Another article explains how constant invalidating a view (which uses an hardware layer) hurts performance.

To draw, you have to call invalidate. Obviously don't call it unless you need it, but if you need to redraw because something changed, we do need to invalidate. I suspect that we're pretty efficient on drawing right now, but am very happy to be shown examples of how we could improve.

Thanks for the research, Peter

[p-lr]

To draw, you have to call invalidate. Obviously don't call it unless you need it, but if you need to redraw because something changed, we do need to invalidate. I suspect that we're pretty efficient on drawing right now, but am very happy to be shown examples of how we could improve.

Yes that's what i thought too. But in the second link, the author talks about animating the alpha property of a view without invalidating for each alpha change, using gpu. I find this very intriguing. Anyway, this needs to be tested. So i created this issue to remind me to do that.

[moagrius]

oh wow - yeah that's definitely worth investigating - good catch

[p-lr]

:D Yes. But, like you, i will believe it when i see it.. Will try that soon.

[p-lr]

+1 on having Tiles control more of their own state, but I'm hesitant about moving Threading logic to the Tile instance because we don't want a 1:1 tile-to-thread - I've spent a lot of time deep in threading recently and have a couple strategies to try; that said, both would have thread management outside of the Tile definition.

You're right. I am editing this issue title to reflect this.

About the hardware layer for alpha animation, i have tested this and it's amazing how we can call something like view.setAlpha(), or view.setRotation() without invalidating and it works (and uses much less the gpu). However, i don't see how it can be applied in our case, as tiles aren't views. TileCanvasViewGroup is a view, but we can't change the alpha of just a region of the view, invoking this method tells the gpu to change the alpha of the bitmap associated with the view.

[moagrius]

+1

unrelated: sorry again, still having trouble getting to this - and i have a bunch of work travel and other stuff going on for the next month or two. if you don't mind waiting, we're good to go - if you're getting impatient and feel like updating, feel free - if you're hesitant to do a bunch of work you're not sure will get committed, you can do micro-PRs that aren't feature complete but let us manage things atomically - but like i said, i have no problem doing the changes as soon as i get the time.

[p-lr]

unrelated: sorry again, still having trouble getting to this

No worries. I will be on holiday soon, and i'm back in August. I will think about v3 stuff and micro-PR in the meanwhile.

[moagrius]

Tiles manager their own state in v3. Closing.