Implement GLSurfaceView #5766
Comments
bleege
added
performance
SurfaceView vs GLSurfaceViewGLSurfaceView is based on SurfaceView and provides the following features:
The biggest difference will be that GLSurfaceView sets up the EGL configuration and provides a dedicated render (thread). These two differences will resolve some issues we have been seeing on Migration
cc @mapbox/android |
|
I was able to get the map to render:
Note that this is not a full working map, it only renders. update: I wasn't able to make above implementation work without crashing. |
|
Capturing from chat that map object needs created and live on the render thread. Creating the map object calls into the platform specific AsyncTask::Impl. I'm currently hitting a crash when RunLoop::Impl is created as part of it. After reading some of the comments there: // This is needed only for the RunLoop living on the main thread because of
// how we implement timers. We sleep on `ALooper_pollAll` until the next
// timeout, but on the main thread `ALooper_pollAll` is called by the activity
// automatically, thus we cannot set the timeout. Instead we wake the loop
// with an external file descriptor event coming from this thread.I'm thinking that current implementation is optimized to work with the main thread and we need some changes to make it work from the render thread. |
|
WIP PR in #7736 |
|
In #7736, I have setup where I'm creating the Map object on the main thread and using the GLSurfaceView created egl components (context, display). This is working, as-is, but we aren't rendering on the render thread yet. When attempting to move invocation to the render thread I'm seeing eg. parent.invoke(&GeometryTile::onLayout, GeometryTile::LayoutResult {
std::move(buckets),
std::move(featureIndex),
*data ? (*data)->clone() : nullptr,
correlationID
});Related stacktrace: Since this is a crash found in core code and not the android binding specific c++ code. I'm going to revisit creating the map object on the render thread. This requires resolving the RunLoop crash at startup. Related stacktrace: |
|
Thanks the team Is this problem already fixed in 5.0.0 release? If not, could you please tell me the release plan? (We met the problem which has similar stack trace) |
|
@ntomizawa Unfortunately |
|
Next steps for introducing rendering on a separate thread in #8820. |
|
A public class GLMapViewRenderer implements GLSurfaceView.Renderer {
private static final String TAG = "MyGLRenderer";
@Override
public void onSurfaceCreated(GL10 unused, EGLConfig config) {
GLES20.glClearColor(1.0f, 0.0f, 0.0f, 1.0f);
}
@Override
public void onDrawFrame(GL10 unused) {
GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT | GLES20.GL_DEPTH_BUFFER_BIT);
}
@Override
public void onSurfaceChanged(GL10 unused, int width, int height) {
GLES20.glViewport(0, 0, width, height);
}
}
The Android Activity Lifecycle supports "pausing" an activity. This happens when the activity goes into the background (e.g. when another activity is shown), but also when e.g. a dialog is shown(!). By default, The API supports a call named Here are a few things that we have to be aware of:
I'm starting to believe that the best architecture for this is to have an "orchestration" thread that holds the Potential issues I'm seeing:
Useful Links |
|
done with #9576 |
This ticket is where work on refactoring Mapbox Android to use
GLSurfaceViewwill take place.In #5000 it was originally proposed to bring back
SurfaceViewandGLSurfaceViewin favor ofTextureViewto increase performance of Map rendering and interactivity. While working on #5000 it was suggested to the team to implementSurfaceViewfirst as it's a more straightforward implementation and doesn't require as much Core GL / C++ work while still providing a performance improvement so that's the direction the ticket took. To keep things more clear, compartmentalized, and easier to track we decided to break the two implementations up into separate tickets./cc @mapbox/mobile
The text was updated successfully, but these errors were encountered: