Code review comment for lp:~afrantzis/mir/android-fix-memory-error

> you're right that we can't manage this object's deletion with our
> std::shared_ptr... but we also don't have a route to free up the framebuffers.
> (other than the process dying, where the kernel will free them up)

From my experimentation, I was given the impression that the native window type
is freed when the associated EGLSurface is destroyed. Is this not the case?

> long story short.... this problem hits 'the perfect storm' of hybris
> limitations and silly android classes.
> I just ported the annoying class over into our 3rd party, hope to mp, kill the
> strange dependency, and make multithreaded compositor landable for android.
>
> I'm going to disapprove, in favor of porting the type over

Always happy for a better way of doing things :)