This repository was archived by the owner on Feb 25, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] separate algorithm for computing render target size. #54604
Merged
auto-submit
merged 38 commits into
flutter:main
from
jonahwilliams:render_target_sizing
Aug 31, 2024
Merged
Changes from 12 commits
Commits
Show all changes
38 commits
Select commit
Hold shift + click to select a range
9d59af1
[Impeller] separate algorithm for computing render target size.
a935594
++
7aa3a48
Update save_layer_utils_unittests.cc
54cea5a
nolint.
e6e56d8
oh boy here we go.
98a5d68
cleanups.
81ccaa0
remove print.
55a6a50
Update save_layer_utils_unittests.cc
3591395
dont overwrite save layer bounds.
a8f0e2c
Merge branch 'render_target_sizing' of github.com:jonahwilliams/engin…
1c55cf5
++
a6f5f21
Update dl_dispatcher.cc
a646c1b
++
8daf291
Merge branch 'main' of github.com:flutter/engine into render_target_s…
199a846
++
b2eb6b9
++
d347783
++
24442e0
flood clip.
78b7f60
add flood clip.
2a4ac2d
++
3eff88b
++
04b5be5
Update entity_pass.cc
086abb8
Update entity_pass.h
4a5f30b
++
fa3afcc
Merge branch 'render_target_sizing' of github.com:jonahwilliams/engin…
4e7a707
partial review feedback.
e0105d7
more adjustments.
e8f34ac
oops
8a3d1ef
Merge branch 'main' into render_target_sizing
24ef59a
Merge branch 'main' into render_target_sizing
0cae7a8
flar review.
ae57e62
Merge branch 'main' of github.com:flutter/engine into render_target_s…
bc2276e
no bds from caller.
b3ab833
update comment.
334e5e9
++
82a6621
++
5011b3c
++
008b6f9
++
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
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.
The "bounds from caller" hint isn't useful here AFAICT. If it matters then the bounds are being used wrong. I use it internally in the Builder to know if the recorded op has bounds from the caller or "dummy" bounds. I then combine the 2 in the restore call. At that point "bounds from caller" has essentially completed its entire "raison d'être" and is obsolete. I leave it in there because it isn't really useful to delete it - the receiver's shouldn't have any use for it.
In all cases the bounds are the bounds of the content of the saveLayer. How they were determined may be interesting, but not really relevant to the fact that they are accurately the bounds of what the code between the saveLayer and its corresponding restore draw, potentially clipped by the user supplied bounds (in which case the "clipped" flag will be set in the options.
When determining how much to allocate, you would determine:
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.
Another way to look at this, the saveLayer will cause 2 kinds of rendering:
The saveLayer bounds may be irrelevant if the BDF says "I plan to render to the entire surface" then what does it matter what the saveLayer content does? But, if we ask the BDF "what's your output if you transform these pixels expressed in the device coordinate system by the BDF acting in the CTM?" then the 2 bounds may need to be combined.