-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Refactor GL context creation and headless rendering #6596
Conversation
The main issue I'm currently seeing is the coupling between an OpenGL context and an object we can render to. It's currently one object, represented by the |
A few tasks that I've previously started that I think would be related to this work:
|
@kkaefer, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jfirebaugh, @mikemorris and @tmpsantos to be potential reviewers. |
789daa1
to
e307fdf
Compare
@jfirebaugh @tmpsantos @brunoabinader @mikemorris This is finally in a good shape and ready for review. I implemented pretty much exactly what is described above. In particular, the only remaining (new) method of a This pull request unlocks a few other tasks that aren't part of this PR yet:
|
e307fdf
to
02e6151
Compare
Refs #6383 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kudos, this looks like a great refactor. I like the fact that neither View
nor Backend
have a dependency on Map
, as View
did before. This eliminates a troublesome circular dependency.
Just some small nits and one TODO to finish up.
#include <mbgl/platform/default/headless_display.hpp> | ||
#include <mbgl/platform/default/headless_view.hpp> | ||
#include <mbgl/platform/default/headless_backend.hpp> | ||
#include <mbgl/platform/default/offscreen_view.hpp> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense as a followup to rename Headless ⇢ Offscreen for consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't rename this to have a difference in naming: Offscreen rendering doesn't necessarily imply headless rendering (and vice versa): We can use Offscreen views/texturs in regular rendering as well.
@@ -26,7 +26,8 @@ namespace android { | |||
void CustomLayer::update(jni::JNIEnv&) { | |||
Log::Debug(mbgl::Event::JNI, "Updating map"); | |||
if (map) { | |||
map->update(mbgl::Update::Repaint); | |||
// TODO: trigger a rerender |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need this implemented before merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
implemented
|
||
class Framebuffer { | ||
public: | ||
// Framebuffer(std::array<uint16_t, 2> size_, gl::UniqueFramebuffer framebuffer_) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete?
|
||
namespace mbgl { | ||
|
||
class Map; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused.
#include <mbgl/util/image.hpp> | ||
|
||
#include <array> | ||
#include <functional> | ||
#include <memory> | ||
|
||
namespace mbgl { | ||
|
||
class Map; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused.
@@ -1,63 +1,22 @@ | |||
#pragma once | |||
|
|||
#include <mbgl/map/change.hpp> | |||
#include <mbgl/util/chrono.hpp> | |||
#include <mbgl/util/image.hpp> | |||
|
|||
#include <array> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused.
@@ -1,63 +1,22 @@ | |||
#pragma once | |||
|
|||
#include <mbgl/map/change.hpp> | |||
#include <mbgl/util/chrono.hpp> | |||
#include <mbgl/util/image.hpp> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused.
02e6151
to
6a555ce
Compare
@jfirebaugh please review again |
We currently have a
View
object, which is a weird mix of GL context creating, framebuffer management, as well as size + pixel ratio management. Instead, I propose refactoring this as follows:Backend
creates/destroys an OpenGL context (if needed). Contains thegl::Context
object. Must be used to initializeMap
andCanvas
objects. ABackend
can support multipleMap
objects.Map
objects are initialized with a fixed pixel ratio; we don't support changing pixel ratio on-the-fly anyway because it is tied to what resources are being loaded.Map
objects can be resized, in logical units (unrelated to the pixel ratio). This affects what tiles are being loaded. It is not tied to a framebuffer orView
object.Map
objects can take a lambda/std::function
that is called when the map should be redrawnView
: abstract class that represents something that we can draw upon. Everyrender/renderStill
call gets passed aView
object. TheMap
andView
objects must be initialized with the sameBackend
object.OffscreenView
is an implementation that draws to the framebuffer. Supports methods for obtaining the image rendered.OffscreenTexture
is similar toOffscreenView
, except that it draws to a texture which can then be used for rendering to other views.Open questions:
renderStillImage
, it doesn't need to block as long as the event loop continues to run. We should only issue GL calls when we are finally drawing the image/cc @mikemorris @jfirebaugh