Skip to content
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 12 commits into from
Apr 18, 2024
Merged

New renderer #1240

merged 12 commits into from
Apr 18, 2024

Conversation

yshui
Copy link
Owner

@yshui yshui commented Apr 14, 2024

No description provided.

@yshui yshui force-pushed the render-planner branch 5 times, most recently from a319a68 to be17913 Compare April 14, 2024 09:27
Copy link

codecov bot commented Apr 14, 2024

Codecov Report

Attention: Patch coverage is 70.60870% with 338 lines in your changes are missing coverage. Please review.

Project coverage is 40.40%. Comparing base (6c925e7) to head (3ca048e).

Additional details and impacted files

Impacted file tree graph

@@            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     
Files Coverage Δ
src/backend/backend_common.c 10.62% <ø> (-36.91%) ⬇️
src/backend/gl/gl_common.h 5.35% <ø> (-13.88%) ⬇️
src/common.h 44.82% <ø> (-37.94%) ⬇️
src/config.c 48.83% <ø> (-0.14%) ⬇️
src/config.h 23.52% <ø> (ø)
src/types.h 100.00% <100.00%> (ø)
src/win.c 72.27% <100.00%> (+2.91%) ⬆️
src/win.h 100.00% <ø> (+17.07%) ⬆️
src/backend/gl/blur.c 0.00% <0.00%> (ø)
src/backend/gl/egl.c 19.25% <60.00%> (+0.40%) ⬆️
... and 11 more

... and 3 files with indirect coverage changes

@yshui yshui force-pushed the render-planner branch 3 times, most recently from 0bd479b to 41b7f37 Compare April 16, 2024 12:01
@yshui yshui changed the title Better damage calculation New renderer Apr 16, 2024
@yshui yshui force-pushed the render-planner branch 13 times, most recently from fdd46b0 to 68eee3e Compare April 17, 2024 12:26
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]>
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]>
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]>
@yshui yshui merged commit 639fba0 into next Apr 18, 2024
18 checks passed
@yshui yshui deleted the render-planner branch April 18, 2024 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant