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

Make it possible to tweak the maximum texture size. #877

Merged
merged 1 commit into from Feb 20, 2017

Conversation

@nical
Copy link
Collaborator

nical commented Feb 14, 2017

As a prelude to the work on supporting very large images, this pull request makes it possible to lower the maximum texture size. By default the maximum size is the one reported by GL and we can lower it with a setting in the RendererOptions (but not increase it).

This should make it a lot easier to test support for large images, will give us the possibility to cap the maximum size for drivers that are too optimistic for their own sake, and also make it easier to reproduce bugs happening on hardware with lower capabilities.

r? @glennw


This change is Reviewable

Copy link
Member

glennw left a comment

image.rs seems to be added as an empty file?

}
}

pub fn max_texture_size(&self) -> u32 { self.max_texture_size }

This comment has been minimized.

@glennw

glennw Feb 15, 2017

Member

nit: There should be a new line here (unless there is something in the rust style guide specifically about this?).

@@ -235,6 +235,8 @@ impl ResourceCache {
}
}

pub fn max_texture_size(&self) -> u32 { self.texture_cache.max_texture_size() }

This comment has been minimized.

@glennw

glennw Feb 15, 2017

Member

nit: newline

@@ -675,7 +675,12 @@ impl Renderer {
options.precache_shaders)
};

let mut texture_cache = TextureCache::new();
let device_max_size = device.max_texture_size();
let max_texture_size = options.max_texture_size

This comment has been minimized.

@glennw

glennw Feb 15, 2017

Member

nit: This can avoid the map with something like:

cmp::min(device_max_size, options.max_texture_size.unwrap_or(device_max_size))
@@ -556,16 +556,23 @@ pub struct AllocationResult {
}

impl TextureCache {
pub fn new() -> TextureCache {
pub fn new(mut max_texture_size: u32) -> TextureCache {
if max_texture_size * max_texture_size > MAX_RGBA_PIXELS_PER_TEXTURE {

This comment has been minimized.

@glennw

glennw Feb 15, 2017

Member

nit: could probably just be a cmp::min()

}
}

pub fn max_texture_size(&self) -> u32 { self.max_texture_size }

This comment has been minimized.

@glennw

glennw Feb 15, 2017

Member

nit: newline

@nical nical force-pushed the nical:max_image_size branch from cc96f40 to 6355390 Feb 15, 2017
@glennw
Copy link
Member

glennw commented Feb 16, 2017

Looks good, let's squash these and then r=me

@nical nical mentioned this pull request Feb 17, 2017
@nical nical force-pushed the nical:max_image_size branch from 6355390 to 1a4fec1 Feb 17, 2017
@glennw
Copy link
Member

glennw commented Feb 19, 2017

This seems to have an extra commit in it now? (The separate out debug/release builds commit).

@glennw
Copy link
Member

glennw commented Feb 19, 2017

r=me once that stray commit is removed.

@nical nical force-pushed the nical:max_image_size branch from 1a4fec1 to 1eb2646 Feb 20, 2017
@glennw
Copy link
Member

glennw commented Feb 20, 2017

@bors-servo
Copy link
Contributor

bors-servo commented Feb 20, 2017

📌 Commit 1eb2646 has been approved by glennw

@bors-servo
Copy link
Contributor

bors-servo commented Feb 20, 2017

Testing commit 1eb2646 with merge 3edfffa...

bors-servo added a commit that referenced this pull request Feb 20, 2017
Make it possible to tweak the maximum texture size.

As a prelude to the work on supporting very large images, this pull request makes it possible to lower the maximum texture size. By default the maximum size is the one reported by GL and we can lower it with a setting in the RendererOptions (but not increase it).

This should make it a lot easier to test support for large images, will give us the possibility to cap the maximum size for drivers that are too optimistic for their own sake, and also make it easier to reproduce bugs happening on hardware with lower capabilities.

r? @glennw

<!-- 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/877)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Feb 20, 2017

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

@bors-servo bors-servo merged commit 1eb2646 into servo:master Feb 20, 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
bors-servo added a commit that referenced this pull request Feb 23, 2017
Tiled image support

Here is a pretty straightforward implementation of image tiling which aims at being able to render images (and vector images) that are larger than the maximum texture size.

The change mostly boils down to:
 - making it possible to upload textures with an offset in the source buffer
 - identifying individual tiles in the resource cache (See ```ImageRequest::tile```)
 - break up image display items into several primitives when the image is tiled

The current limitation is that repeating images isn't supported with tiling yet. That will need to be fixed. It should only be a matter of extending the code in frame.rs so that it generate a set of image primitive for each repetition.

I have been changing my mind regularly on the topic of whether tiling should be requested explicitly in the API or if it should be done somewhat automatically inside of WebRender. Currently I think that making this explicit in the API is simpler to implement and also simpler to test, so that's what I ended up implementing. It would probably make sense to also automatically tile images that are larger than the maximum texture size even if tiling isn't requested, because there isn't any way to render them otherwise.
I don't have a particular attachment to the way I exposed it in the api (added ```RenderApi::add_image_with_tiling``` rather than passing an extra parameter in add_image to avoid changing the api), let me know if you have a preference.

I am quite happy with how this works compared to what we have in gecko's layers, because tiles are uploaded on-demand which means we don't need to pay unnecessary cost for large images that are partially visible.

The separation between the commits isn't too bad so I kept it this way in case it helps with the review, but don't hesitate to ask me to squash it into one commit before the review if you prefer. Also the PR is rebased on top of PR #877 which makes more code appear here than it should, but this will clear out when the latter PR lands.

r? @glennw @kvark

<!-- 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/897)
<!-- Reviewable:end -->
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

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