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

Separate FrameBuilder into it's own file #834

Merged
merged 2 commits into from Feb 6, 2017

Conversation

@mrobinson
Copy link
Member

mrobinson commented Feb 6, 2017

This is the first step toward splitting up tiling.rs into logical
units and will help to reduce merge conflicts in the future.


This change is Reviewable

This is the first step toward splitting up tiling.rs into logical
units and will help to reduce merge conflicts in the future.
@mrobinson
Copy link
Member Author

mrobinson commented Feb 6, 2017

@glennw or @kvark r?

This can be part of the configuration structure instead of a free
parameter.
@kvark
Copy link
Member

kvark commented Feb 6, 2017

I think the PR closes #587

@mrobinson
Copy link
Member Author

mrobinson commented Feb 6, 2017

@kvark It does help, but I still think there is more work to do. tiling.rs still contains many things that can be moved out. 😄

@kvark
kvark approved these changes Feb 6, 2017
Copy link
Member

kvark left a comment

I'm not a fan of public-exposing everything, but otherwise looks good.

stacking_context_store: &'a [StackingContext],
prim_store: &'a PrimitiveStore,
resource_cache: &'a ResourceCache,
pub struct RenderTargetContext<'a> {

This comment has been minimized.

@kvark

kvark Feb 6, 2017

Member

Can we have the fields hidden and only exposed to the module that uses them?
I imagine that both tiling and frame_builder need to create a RenderTargetContext, but do they both need to access the fields?

clip_cache_info: Option<MaskCacheInfo>,
packed_layer_index: PackedLayerIndex,
xf_rect: Option<TransformedRect>,
pub scroll_layer_id: ScrollLayerId,

This comment has been minimized.

@kvark

kvark Feb 6, 2017

Member

ok, so there is a lot of stuff that is now public
I suppose we can address the privacy concerns in follow-ups

This comment has been minimized.

@mrobinson

mrobinson Feb 7, 2017

Author Member

I agree. I think once everything has been moved it makes sense to go back and reduce the visibility of everything by adding methods to the structs.

@glennw
Copy link
Member

glennw commented Feb 6, 2017

@bors-servo
Copy link
Contributor

bors-servo commented Feb 6, 2017

📌 Commit c0e9b84 has been approved by glennw

@bors-servo
Copy link
Contributor

bors-servo commented Feb 6, 2017

Testing commit c0e9b84 with merge a517c70...

bors-servo added a commit that referenced this pull request Feb 6, 2017
Separate FrameBuilder into it's own file

This is the first step toward splitting up tiling.rs into logical
units and will help to reduce merge conflicts in the future.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/834)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Feb 6, 2017

☀️ Test successful - status-travis
Approved by: glennw
Pushing a517c70 to master...

@bors-servo bors-servo merged commit c0e9b84 into servo:master Feb 6, 2017
3 checks passed
3 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@mrobinson
Copy link
Member Author

mrobinson commented Feb 7, 2017

Thanks for the reviews.

@mrobinson mrobinson deleted the mrobinson:frame-builder branch Feb 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.