When creating a Linux surface XCreatePixmap is called with an invalid depth.

This is in order to complete servo/servo#140.

So, I've forked the repo, and made some changes, but whenever I try to build I get an error saying "can't find crate for 'geom'." I'm rather new to rust, and can't seem to get geom to install with rustpkg--as there is no main.rs/lib.rs/etc file.

Does there exist documentation on contributing to servo submodules?

Also, anyone have any objections to me importing azure, and having the background_color field just be a AzColor?

Help would be greatly appreciated!

1. git clone https://github.com/servo/rust-layers && cd rust-layers
2. cargo build

Produces following error code output:

    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/servo/skia`
    Updating git repository `https://github.com/servo/rust-azure`
    Updating git repository `https://github.com/servo/rust-glx`
    Updating git repository `https://github.com/servo/io-surface-rs`
    Updating git repository `https://github.com/servo/rust-egl`
no matching package named `skia` found (required by `layers`)
location searched: https://github.com/servo/skia
version required: *

I am new to rust so it's also likely I'm doing something wrong, but not sure what because the location https://github.com/servo/skia does exist. Do you get the same error?

NativeCompositingGraphicsContext::compositor_visual_info does only choose RGBA GL visuals, but NVidida drivers include visuals that support RGBA in OpenGL, but not in their associated X11 visuals. This means that the Pixmaps created using these visual do not have a corresponding alpha channel. When using data from these Pixmaps, a missing alpha channel can be interpreted as 0 alpha everywhere, leading to invisible layers.

There's a lot of platform-specific code here; we should test on all of them.

CC @larsbergstrom @metajack

Documentation link is broken.

I’m in the middle of replacing uint with usize. But when it’s for geometry, maybe it should be u32 instead?

There is exactly one call to glGetError and it's in the linux port. This is useless, as an error could have occurred literally anywhere and would only be detected here, giving a false positive about what may have occurred.

All the types for which we derive HeapSizeOf could just use known_heap_size!(0, ...);.

Multi-OS support is not public on Travis, so we'd be limited to linux. That said, I think it's better than nothing; it would have prevented #171