multigpu: Less constraints around framebuffers #1816
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The are a couple of commits that evolved around trying to use the
cross_renderer
with a GL-based and the pixman renderer.(The biggest blocker for that is that the PixmanRenderer doesn't support it's own texture type as a framebuffer, because client shm
WlBuffer
s. I have a commit "fixing" that, but it is ugly and I don't pursue this any more.)Either way these commits are standalone and useful on their own. They can be reviewed one-by-one.
target
in theMultiRenderer
, we know thatR == T
(because the only way to get that is viacross_renderer
, which always setstarget
). This we can have theFramebuffer
-type only depend onT
with some transmutes and remove the constraints onR
. I am fairly certain this is correct and it doesn't crash, but I'd certainly appreciate a second look on this one.