-
-
Notifications
You must be signed in to change notification settings - Fork 589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New renderer #1240
Merged
Merged
New renderer #1240
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yshui
force-pushed
the
render-planner
branch
5 times, most recently
from
April 14, 2024 09:27
a319a68
to
be17913
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## next #1240 +/- ##
==========================================
+ Coverage 38.39% 40.40% +2.01%
==========================================
Files 55 59 +4
Lines 12073 12534 +461
==========================================
+ Hits 4635 5064 +429
- Misses 7438 7470 +32
|
yshui
force-pushed
the
render-planner
branch
3 times, most recently
from
April 16, 2024 12:01
0bd479b
to
41b7f37
Compare
yshui
force-pushed
the
render-planner
branch
13 times, most recently
from
April 17, 2024 12:26
fdd46b0
to
68eee3e
Compare
The layout manager tracks the overall window layout for each frame, which can later be used to plan rendering. The goal is to provides a more principled way of damage tracking. Currently what we do is just sprinkling `add_damage_from_win` everywhere in the code. And hope we didn't forget a place. This is error prone and the result damage is also imprecise. Getting damage right for animations using that method would be a nightmare. The layout manager is the first step of solving that problem. Signed-off-by: Yuxuan Shui <[email protected]>
The command builder generates a list of backend operations needed to render a layout. The goal is two fold: 1. Help with backend interface transition. The command builder generates calls of the new interface, with it we will be able to remove the compat layer. 2. Reduce code duplication. Several places in the code need to know how windows are rendered. We need that info to compare past and current layouts to figure out the overall damage region; we need that info to figure out which part of each render command is visible in the final result, and clip out unnecessary regions; and finally we need that info to actually render. I don't want to repeat the same code three times. So instead we generate all the render steps at once as commands, then operate on those commands. Right now this function is called and the results logged, otherwise it's not used. Signed-off-by: Yuxuan Shui <[email protected]>
…ilder Signed-off-by: Yuxuan Shui <[email protected]>
The renderer is the orchestrator of all the rendering components, like the layout manager, the command builder, etc. It takes a layout from the core, generate commands for it using command builder, potentially post-process it, and then send the commands off to the backend to be executed. Right now this renderer is incomplete, it doesn't support rendering with damages, or monitor repaint. Signed-off-by: Yuxuan Shui <[email protected]>
Environment variables are global anyway. Move those into to global variable so we don't need `struct session` to access them. Signed-off-by: Yuxuan Shui <[email protected]>
So we can test out the new renderer without disrupting users. Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
So far, in old or new backends, monitor repaint only shows you where the damage regions are. But enabling it actually disables `use-damage`, meaning if you have a bug with damage, enabling monitor repaint and it will disappear. And I would have to compare the damage regions with and without monitor repaint to figure things out. This commit makes monitor repaint use damage too. This is only possible with the new v2 renderer and new backend interface. Signed-off-by: Yuxuan Shui <[email protected]>
And remove the old new backend interface, and compatibility layer, and remove unneeded functions and types. Signed-off-by: Yuxuan Shui <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.