servo / surfman

Accelerated offscreen graphics for WebGL

The Servo Parallel Browser Engine Project

Servo is a prototype web browser engine written in the Rust language. It is currently developed on 64-bit macOS, 64-bit Linux, 64-bit Windows, and Android.

Servo welcomes contribution from everyone. See CONTRIBUTING.md and HACKING_QUICKSTART.md for help getting started.

Visit the Servo Project page for news and guides.

Getting Servo

git clone https://github.com/servo/servo
cd servo

• Your CARGO_HOME needs to point to (or be in) the same drive as your Servo repository (#28530).
• The Servo repository is big! If you have an unreliable network connection, consider making a shallow clone.

Build Setup

• macOS
• Linux
• Windows
• Android

If these instructions fail or you would like to install dependencies manually, try the manual build setup.

macOS

• Ensure that the version showed by python --version is >= 3.10:
• Install Xcode
• Install Homebrew
• Run curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
• Run ./mach bootstrap
  Note: This will install the recommended version of GStreamer globally on your system.

Linux

• Run curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
• Install Python (version >= 3.10):
  • Debian-like: Run sudo apt install python3-pip python3-venv
  • Fedora: Run sudo dnf install python3 python3-pip python3-devel
  • Arch: Run sudo pacman -S --needed python python-pip
  • Gentoo: Run sudo emerge dev-python/pip
• Run ./mach bootstrap

Windows

• Download and run rustup-init.exe
• Make sure to select Quick install via the Visual Studio Community installer or otherwise install Visual Studio 2022.
• In the Visual Studio Installer ensure the following components are installed for Visual Studio 2022:
  • Windows 10 SDK (10.0.19041.0) (Microsoft.VisualStudio.Component.Windows10SDK.19041)
  • MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest) (Microsoft.VisualStudio.Component.VC.Tools.x86.x64)
  • C++ ATL for latest v143 build tools (x86 & x64) (Microsoft.VisualStudio.Component.VC.ATL)
  • C++ MFC for latest v143 build tools (x86 & x64) (Microsoft.VisualStudio.Component.VC.ATLMFC)
• Install chocolatey
• Install Python 3.11
• Run mach bootstrap
  • This will install CMake, Git, and Ninja via choco in an Administrator console. Allow the scripts to run and once the operation finishes, close the new console.
• Run refreshenv

See also Windows Troubleshooting Tips.

Android

• Ensure that the following environment variables are set:
  • ANDROID_SDK_ROOT
  • ANDROID_NDK_ROOT: $ANDROID_SDK_ROOT/ndk/25.2.9519653/ ANDROID_SDK_ROOT can be any directory (such as ~/android-sdk). All of the Android build dependencies will be installed there.
• Install the latest version of the Android command-line tools to $ANDROID_SDK_ROOT/cmdline-tools/latest.
• Run the following command to install the necessary components:

  sudo $ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager --install
   "build-tools;33.0.2" \
   "emulator" \
   "ndk;25.2.9519653" \
   "platform-tools" \
   "platforms;android-33" \
   "system-images;android-33;google_apis;x86_64"

For information about building and running the Android build, see the Android documentation.

Building

Servo is built with Cargo, the Rust package manager. We also use Mozilla's Mach tools to orchestrate the build and other tasks. You can call Mach like this:

On Unix systems:

./mach [command] [arguments]

On Windows Commandline:

mach.bat [command] [arguments]

The examples below will use Unix, but the same applies to Windows.

The Rust compiler

Servo's build system uses rustup.rs to automatically download a Rust compiler. This is a specific version of Rust Nightly determined by the rust-toolchain.toml file.

Normal build

To build Servo in development mode. This is useful for development, but the resulting binary is very slow:

./mach build --dev
./mach run tests/html/about-mozilla.html

Release build

For benchmarking, performance testing, or real-world use. Add the --release flag to create an optimized build:

./mach build --release
./mach run --release tests/html/about-mozilla.html

Android build

For an armv7 Android build run the following command.

./mach build --android

Checking for build errors, without building

If you’re making changes to one crate that cause build errors in another crate, consider this instead of a full build:

./mach check

It will run cargo check, which runs the analysis phase of the compiler (and so shows build errors if any) but skips the code generation phase. This can be a lot faster than a full build, though of course it doesn’t produce a binary you can run.

Running

Run Servo with the command:

./servo [url] [arguments] # if you run with nightly build
./mach run [url] [arguments] # if you run with mach

# For example
./mach run https://www.google.com

Commandline Arguments

• -p INTERVAL turns on the profiler and dumps info to the console every INTERVAL seconds
• -s SIZE sets the tile size for painting; defaults to 512
• -z disables all graphical output; useful for running JS / layout tests
• -Z help displays useful output to debug servo

Keyboard Shortcuts

• Ctrl+L opens URL prompt (Cmd+L on Mac)
• Ctrl+R reloads current page (Cmd+R on Mac)
• Ctrl+- zooms out (Cmd+- on Mac)
• Ctrl+= zooms in (Cmd+= on Mac)
• Alt+left arrow goes backwards in the history (Cmd+left arrow on Mac)
• Alt+right arrow goes forwards in the history (Cmd+right arrow on Mac)
• Esc or Ctrl+Q exits Servo (Cmd+Q on Mac)

Runtime dependencies

Linux

• GStreamer >=1.18
• gst-plugins-base >=1.18
• gst-plugins-good >=1.18
• gst-plugins-bad >=1.18
• gst-plugins-ugly >=1.18
• libXcursor
• libXrandr
• libXi
• libxkbcommon
• vulkan-loader

Developing

There are lots of mach commands you can use. You can list them with ./mach --help.

The generated documentation can be found on https://doc.servo.org/servo/index.html

surfman's Issues

The 'threads' example fails on windows machine

OS: Windows 10 build 19041.746
GPU: AMD Radeon R9 390, Radeon software version 20.11.2
Built from commit d6403d1

On running the example, this assert triggers:
assert!(!gl_dx_interop_device.is_null());
in file surfman/src/platform/windows/wgl/device.rs: 157

Checking the error code with errhandlingapi::GetLastError returns 13, or ERROR_INVALID_DATA.
I don't know what to make of this, because wglDXOpenDeviceNV supposedly only generates ERROR_OPEN_FAILED or
ERROR_NOT_SUPPORTED. Checking GetLastError prior to the call to wglDXOpenDeviceNV returns 0, ERROR_SUCCESS.

Offscreen demo crash on macOS 14/15

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1286`,
 right: `0`', surfman/examples/common/mod.rs:141:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Use texture sharing instead of shared GL context

This would avoid #82 and give us fast WebGL rendering on macOS (per servo/servo#11138 (comment)), as well as the benefits described by servo/rust-webvr#54 (comment).

The root of the problem is that Servo used shared OpenGL contexts to share WebGL textures
instead of using texture primitives that could be shared among different threads/processes
without requiring a shared GL context (e.g. SurfaceTextures on Andriod, IOSurface on Mac, etc)

Remove metal dependency

It's surprisingly used in the public API, and functionally only called with this:

MetalDevice::all().into_iter().filter(|device| device.is_low_power())

Sine metal updates more often than surfman, it would be preferred to not depend on metal. In this case, just exposing cocoa::id in public API and issuing objc messages for that function should be enough.

rust-offscreen-rendering-context does not link to using libraries

rust-offscreen-rendering-context became to use dynamic gl context. But by its change, gleam does not link to gl libraries, since it does not link to them. rust-offscreen-rendering-context calls gl library functions like glXGetCurrentContext, but rust-offscreen-rendering-context does not link to necessary gl libraries. It causes link error when building webrender. The functions are used by rust-offscreen-rendering-context, then they should be linked by rust-offscreen-rendering-context.

Test Windows backend, probably using AppVeyor.

cc @MortimerGoro

ANGLE backend's SurfaceTexture should unbind the texture image in its destructor

I remember tracking down a memory leak to the missing unbind when I was creating lots of surface textures rapidly.

Type declaration for egl NativeGLContextHandle doesn't match its use

In https://github.com/servo/rust-offscreen-rendering-context/blob/69505baa96b8e66a1a6b04ca43b6b8c755ba4ed3/src/platform/with_egl/native_gl_context.rs#L137 there is:

    NativeGLContextHandle(native_context, native_display)

but the type declaration at https://github.com/servo/rust-offscreen-rendering-context/blob/69505baa96b8e66a1a6b04ca43b6b8c755ba4ed3/src/platform/with_egl/native_gl_context.rs#L24 is:

    pub struct NativeGLContextHandle(pub EGLDisplay, pub EGLSurface);

This works because the uses are all consistent, and they're just typedefs for void*.

Use Surfman with webrender couldn't render fonts?

It seems that surfman do not support webrender's font render, I try to impl Webrender's multiwindow example with surfman, I did get the rect，but no fonts got rendered.
I did those steps:

        let font_key = self.webrender_api.generate_font_key();
        let font_bytes = load_file(font_path);

        let mut txn = Transaction::new();
        txn.add_raw_font(font_key, font_bytes, 0);

        let font_instance_key = self.webrender_api.generate_font_instance_key();
        txn.add_font_instance(font_instance_key, font_key, glyph_size, None, None, Vec::new());

        self.webrender_api.send_transaction(self.document_id, txn);

and then put my glyphs into display_list through builder.push_text, but no text are rendered, did I miss some config?

Update cgl to v0.2

servo/cgl-rs#21 is going to update cgl-rs version to 0.2, the change is going to update
gleam.

Add a headless compilation mode.

It would be great if we could build on headless machines that don't have X11 installed. Perhaps a headless feature where only the OSMesa support is enabled?

Decouple surfaces from GL contexts

Moved from pcwalton#65 (comment)

This is a blocker for proper GL support in gfx-rs/wgpu.

@asajeffrey

tl;dr: we might be able to lift the restriction that surfman Surfaces have an associated producer Context that has draw access. This restriction was needed for GLX, but that's not a supported platform any more.

@pcwalton

it might be the case that we can drop the requirement that surfaces are tied to context now
because we're using DXGI to allocate WGL surfaces and we dropped GLX in favor of EGL
I would love to be able to drop that requirement, it's an artificial limitation that doesn't match how GPU hardware actually works obviously
it was purely the product of baroque APIs
this should be supported by the more modern versions of all the APIs were care about
IOSurface is internally completely decoupled from GL contexts, as are DXGI surfaces which are DirectX resources in the first place (not OpenGL)
in modern EGL, a combination of EGLImageKHR and this extension gives you decoupling as well https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_surfaceless_context.txt
the current design is me being a bit overly conservative -- I considered GLX support a requirement at first, and then eventually got fed up with it and found, happily, that I could just drop it
but didn't revisit the design

How can I use surfman and webrender together？

Hi guys，I want to use surfman(as the GL context) and webrender (as the Render engine) to do some Rendering stuff，because surfman use ANGLE on Windows, which should achieve better robustness.
but all examples in webrender use glutin as the GL context, and Servo's implement is too complicated to understand, so I don't know how to achieve that now, I need some help~

Cargo build fails on project root. Cannot run android sample.

ngallinal@ITs-Mac-mini-2 surfman % cargo build
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /Users/ngallinal/Development/surfman/android-example/rust/Cargo.toml
workspace: /Users/ngallinal/Development/surfman/Cargo.toml
   Compiling surfman_android_threads v0.1.0 (/Users/ngallinal/Development/surfman/android-example/rust)
error[E0433]: failed to resolve: use of undeclared type or module `winit`
  --> android-example/rust/src/../../../surfman/examples/threads.rs:20:5
   |
20 | use winit::dpi::PhysicalSize;
   |     ^^^^^ use of undeclared type or module `winit`

error[E0432]: unresolved import `surfman::platform::android`
  --> android-example/rust/src/lib.rs:17:24
   |
17 | use surfman::platform::android::tests;
   |                        ^^^^^^^ could not find `android` in `platform`

error[E0432]: unresolved import `winit`
  --> android-example/rust/src/../../../surfman/examples/threads.rs:22:5
   |
22 | use winit::{DeviceEvent, Event, EventsLoop, KeyboardInput, VirtualKeyCode};
   |     ^^^^^ use of undeclared type or module `winit`

error[E0432]: unresolved import `winit`
  --> android-example/rust/src/../../../surfman/examples/threads.rs:24:5
   |
24 | use winit::{WindowBuilder, WindowEvent};
   |     ^^^^^ use of undeclared type or module `winit`

error[E0433]: failed to resolve: use of undeclared type or module `PhysicalSize`
  --> android-example/rust/src/../../../surfman/examples/threads.rs:91:9
   |
91 |         PhysicalSize::new(window_size.width as f64, window_size.height as f64).to_logical(dpi);
   |         ^^^^^^^^^^^^ use of undeclared type or module `PhysicalSize`

warning: unused `#[macro_use]` import
 --> android-example/rust/src/lib.rs:3:1
  |
3 | #[macro_use]
  | ^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused imports: `JoinHandle`, `self`
  --> android-example/rust/src/lib.rs:16:19
   |
16 | use std::thread::{self, JoinHandle};
   |                   ^^^^  ^^^^^^^^^^

error[E0599]: no function or associated item named `current` found for struct `surfman::platform::macos::system::device::NativeDevice` in the current scope
  --> android-example/rust/src/lib.rs:42:76
   |
42 |     let device = connection.create_device_from_native_device(NativeDevice::current()).unwrap();
   |                                                                            ^^^^^^^ function or associated item not found in `surfman::platform::macos::system::device::NativeDevice`

error: aborting due to 6 previous errors; 2 warnings emitted

Some errors have detailed explanations: E0432, E0433, E0599.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `surfman_android_threads`.

To learn more, run the command again with --verbose.

running on macOS 10.15.6

Spurious test failure of platform::unix::wayland::tests::test_depth_and_stencil

The following assert in the test fails sometimes (approx. 1 out of 5 times):

    unsafe {
        let framebuffer_object = device
            .context_surface_info(&depth_context)
            .unwrap()
            .unwrap()
            .framebuffer_object;
        gl.BindFramebuffer(gl::FRAMEBUFFER, framebuffer_object);
        gl.Viewport(0, 0, 640, 480);

        gl.ClearDepth(0.5);
        gl.Clear(gl::DEPTH_BUFFER_BIT);

        let mut depth_value: f32 = -1.0;
        gl.ReadPixels(
            0,
            0,
            1,
            1,
            gl::DEPTH_COMPONENT,
            gl::FLOAT,
            (&mut depth_value) as *mut f32 as *mut c_void,
        );
        // Note: edited the assertion to output the actual value.
        assert!(approx_eq(depth_value, 0.5), "actual depth value was {}, but expected 0.5", depth_value);
    }

Output:

---- platform::unix::wayland::tests::test_depth_and_stencil stdout ----
thread 'platform::unix::wayland::tests::test_depth_and_stencil' panicked at surfman/src/platform/unix/wayland/../../../tests.rs:785:9:
actual depth value was NaN, but expected 0.5

Tested on Fedora 40.

Consider loading `libEGL.so.1` instead of `libEGL.so`

After the GStreamer update in Servo, the nightly binaries have been failing to launch on linux distros unless libegl1-mesa-dev or equivalent package is installed in the runtime environment.

Based on my investigation here, it seems the root cause of the failure is that surfman is trying to dynamically open and load functions from libEGL.so, but on many systems the symlink from libEGL.so to the versioned shared object i.e libEGL.so.1 doesn't exist unless the libegl1-mesa-dev or equivalent package is installed.

Also, the reason the binaries were loading before the GStreamer update was because the binary had a compile-time link to libEGL.so.1 (due to gstreamer-sys crate, which on nightly is not present after the GStreamer upgrade since we have also disabled the media stack). Because of this compile time link, the dlsym calls are able to succesfully load the functions even though the dlopen('libEGL.so') call returns a null handle, indicating failure.

Additionally, @mrobinson found this issue which indicates other bindings like khronos-egl load libEGL.so.1 instead of libEGL.so.

This issue is to decide if it is a good idea to do the same in surfman. I don't have expertise in EGL, so I am not sure if we still need a fallback to loading libEGL.so if libEGL.so.1 fails to load, like khronos-egl does. I have tested with a patched surfman that loading libEGL.so.1 does indeed fix the egl function was not loaded issues and Servo continues to work.

Force use of particular api

Is it possible to force surfman to use a particular api? On my system (horrible nvidia card, sorry) GlEs works, but Gl doesn't. Glutin returns a GlEs context, whereas surfman hands out a Gl, which subsequently fails (probably due to nonsense in the driver).

offscreen example ConnectionFailed on Ubuntu Server or Docker container

I can't run the offscreen example on Ubuntu Server or docker, any example provide?

uname -a

output:

Linux GPU1 4.4.0-178-generic #208-Ubuntu SMP Sun Apr 5 23:45:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

locate libwayland-client.so

output:

/usr/lib/x86_64-linux-gnu/libwayland-client.so.0
/usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0

Issue building; Looks like my winit is the wrong version, but I don't know how to change it.

I'm building from source, with no additions. But, when I run the code, I get issues with an unresolved import of 'winit'
error[E0433]: failed to resolve: use of undeclared crate or module winit
--> android-example/rust/src/../../../surfman/examples/threads.rs:20:5
|
20 | use winit::dpi::PhysicalSize;
| ^^^^^ use of undeclared crate or module winit

error[E0432]: unresolved import surfman::platform::android
--> android-example/rust/src/lib.rs:17:24
|
17 | use surfman::platform::android::tests;
| ^^^^^^^ could not find android in platform

error[E0432]: unresolved import winit
--> android-example/rust/src/../../../surfman/examples/threads.rs:22:5
|
22 | use winit::{DeviceEvent, Event, EventsLoop, KeyboardInput, VirtualKeyCode};
| ^^^^^ use of undeclared crate or module winit

error[E0432]: unresolved import winit
--> android-example/rust/src/../../../surfman/examples/threads.rs:24:5
|
24 | use winit::{WindowBuilder, WindowEvent};
| ^^^^^ use of undeclared crate or module winit

error[E0433]: failed to resolve: use of undeclared type PhysicalSize
--> android-example/rust/src/../../../surfman/examples/threads.rs:93:9
|
93 | PhysicalSize::new(window_size.width as f64, window_size.height as f64).to_logical(dpi);
| ^^^^^^^^^^^^ use of undeclared type PhysicalSize

warning: unused #[macro_use] import
--> android-example/rust/src/lib.rs:3:1
|
3 | #[macro_use]
| ^^^^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default

warning: unused imports: JoinHandle, self
--> android-example/rust/src/lib.rs:16:19
|
16 | use std::thread::{self, JoinHandle};
| ^^^^ ^^^^^^^^^^

error[E0599]: no function or associated item named current found for struct surfman::NativeDevice in the current scope
--> android-example/rust/src/lib.rs:44:57
|
44 | .create_device_from_native_device(NativeDevice::current())
| ^^^^^^^ function or associated item not found in surfman::NativeDevice

The version of winit that's running on my machine appears to be 0.19.3, and I'm not sure how to move backwards. Any help would be appreciated.

We could send the result of the wglMakeCurrent call through the channel.

(And interrupt context creation if required). I think it'd be a nice to have, even if it's really unlikely.

cc @MortimerGoro

Cannot create context on OpenGL 2.1 GPU

I tried run program that uses surfman for window creation - but it not works, crashes with this error:

thread 'main' panicked at 'TODO: ContextCreationFailed(BadMatch)', src/backend/gl/src/window/surfman.rs:152:27

glxinfo output: https://pastebin.com/XXmSBMCp

[Question] Is it Possible to Target MacOS With OpenGL ES 2.0?

I'm writing a game that uses OpenGL 2.0 for rendering and I'm using surfman and winit to create the graphics context and the window.

I don't have a mac, but a colleage of mine who does tested the game on their mac and get's a solid red screen.

I've heard that OpenGL is deprecated on MacOS before, so I'm not sure if that is the issue or not. I guess I'm mostly trying to get an idea of what the current state of OpenGL support on Mac is.

• Does OpenGL work on macs even though it is depracated and this is just an issue with my game?
• Is it possible to fall back to CPU rendering using mesa on Mac? ( My game is 2D and not super intense so the slowness might not be prohibitive )
• Can we use Angle to support OpenGL ES 2.0 on Metal? According to the angle README, OpenGL ES 2.0 is the only one supported on Metal so far, but that's what I'm already using so that would work for my app.
• Are there any other options I should be aware of for putting an OpenGL app on MacOS?

Make branches for breaking releases

It's useful to have v0.2, v0.3, etc branches to quickly look up the code that was published and be able to produce patch versions on it.

Extract GLLimits and GLContextAttributes into a separate crate

Right now whenever I modify rust-offscreen-rendering-context I have to rebuild the script crate in servo because it relies on these two structures. That makes me very sad.

Format the code

Looks like the code is in dire need of a good rustfmt pass.

Issues with examples on Windows

The threads example shows a plain white window and then exits with

(exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

The offscreen example panics with

thread 'main' panicked at 'gl function was not loaded', D:\personal\software\contribution\surfman\target\debug\build\gl-76f8da451bedeb81\out/bindings.rs:20624:13
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.40\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print_fmt
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\sys_common\backtrace.rs:77
   2: std::sys_common::backtrace::_print::{{impl}}::fmt
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\sys_common\backtrace.rs:59
   3: core::fmt::write
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libcore\fmt\mod.rs:1052
   4: std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\io\mod.rs:1426
   5: std::sys_common::backtrace::_print
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\sys_common\backtrace.rs:62
   6: std::sys_common::backtrace::print
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\sys_common\backtrace.rs:49
   7: std::panicking::default_hook::{{closure}}
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\panicking.rs:204
   8: std::panicking::default_hook
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\panicking.rs:224
   9: std::panicking::rust_panic_with_hook
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\panicking.rs:472
  10: std::panicking::begin_panic<str*>
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\panicking.rs:399
  11: gl::missing_fn_panic
             at D:\personal\software\contribution\surfman\target\debug\build\gl-76f8da451bedeb81\out\bindings.rs:20624
  12: gl::CreateShader
             at D:\personal\software\contribution\surfman\target\debug\build\gl-76f8da451bedeb81\out\bindings.rs:1736
  13: offscreen::common::Shader::new
             at .\examples\common\mod.rs:57
  14: offscreen::TriProgram::new
             at .\examples\offscreen.rs:168
  15: offscreen::TriVertexArray::new
             at .\examples\offscreen.rs:129
  16: offscreen::main
             at .\examples\offscreen.rs:88
  17: std::rt::lang_start::{{closure}}<()>
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\rt.rs:67
  18: std::rt::lang_start_internal::{{closure}}
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\rt.rs:52
  19: std::panicking::try::do_call<closure-0,i32>
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\panicking.rs:305
  20: panic_unwind::__rust_maybe_catch_panic
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libpanic_unwind\lib.rs:86
  21: std::panicking::try
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\panicking.rs:281
  22: std::panic::catch_unwind
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\panic.rs:394
  23: std::rt::lang_start_internal
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\/src\libstd\rt.rs:51
  24: std::rt::lang_start<()>
             at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447\src\libstd\rt.rs:67
  25: main
  26: invoke_main
             at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  27: __scrt_common_main_seh
             at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  28: BaseThreadInitThunk
  29: RtlUserThreadStart

Test OSMesa back-end

It's right now untested on CI.

Are there parts that could use glutin?

#30 made me think that maybe it's time to consolidate and focus on the pieces of this repo that don't make sense in glutin.

Move to crates.io?

First step, avoid git dependencies:

• Move geom to crates.io?
• Auto-generate bindings with gl-rs
• Probably will need to create a branch to publish and delete ther the layers dependency, which is very servo-specific.

Later:

• Use semver
• Rename crate to offscreen_gl
• Rename repo to offscreen-gl-rs

Are there any plans to release v0.4.1?

hi all, i created a pr #225 and it has been merged, in this pr i update the surfman version from 0.4.0 to 0.4.1, are there any plans to release v0.4.1 on https://crates.io/ ? now i can only modify cargo.lock to use new version surfman.

Remove euclid dependency

It's unclear what value euclud brings here. A cursory look reveals only Point2D and Size2D used, and surfman could just roll out its own structures for this.

Support multiple textures

For servo/servo#21841 I would like to be able to have one texture that is ready for webrender at all times, and one texture that is ready for drawing. master...jdm:multiple is my attempt (along with servo/servo@master...jdm:gl) but it's not working correctly yet. @emilio can you advise if I'm missing something?

surfman with winit crashes on Android Emulator

Using surfman with the winit ndk glue results in a crash when creating the window surface on recent Android Emulators, and on cuttlefish (Android's "board" for running the OS in a hypervisor, using virgl).

Surfman's Android platform create_window_surface makes the context current without a draw or read buffer (in order to find out the EGLConfig to specify when making the window surface), which is only supported on "surfaceless contexts" which the Android virtualized EGL doesn't seem to handle. Making the context current fails, and surfman then crashes a little later on attempting to use a null string returned by glGetString.

We can actually just use the get_context_attr and egl_config_from_id functions to get the EGLConfig and avoid making the context current without surfaces.

Accessing CGL native context

Hi there! I'm investigating using this library for a hardware-accelerated image processing library I'm working on, and one of my requirements is that I'm able to get access the native context for each platform I'm deploying on. It seems like the way to do that here is to use GLContext's .handle() method here, and to access the struct's members from there.

However, I ran into a problem when doing this on macOS - I can't figure out a way to actually access the underlying CGLContextObj. I'm pretty new to this library, but it seems that in order to access the native context object, in src/platform/with_cgl/native_gl_context.rs:

pub struct NativeGLContextHandle(CGLContextObj);

should be:

pub struct NativeGLContextHandle(pub CGLContextObj);

Does this make sense, or is there something I'm missing? Thanks so much!

Destructor of `Device` hangs on Windows

To reproduce, run the following code on Windows:

use surfman::Connection;

fn main() {
    let connection = Connection::new().unwrap();

    connection
        .create_device(&connection.create_adapter().unwrap())
        .unwrap();
}

I suspect this is caused by main thread sending WM_CLOSE to the hidden window thread:

surfman/surfman/src/platform/windows/wgl/device.rs

Line 258 in ae14cc9

winuser::SendMessageA(self.window, WM_CLOSE, 0, 0);

But the hidden window thead handles it using GetMessage:

surfman/surfman/src/platform/windows/wgl/device.rs

Line 331 in ae14cc9

while winuser::GetMessageA(&mut msg, window, 0, 0) != FALSE {

According to the Windows API document, GetMessage will only process messages from the message queue, and the messages sent by SendMessage are nonqueued messages, so GetMessage will not pick it up, so the condition will never be true:

surfman/surfman/src/platform/windows/wgl/device.rs

Line 334 in ae14cc9

if minwindef::LOWORD(msg.message) as UINT == WM_CLOSE {

Support EGL on wayland

Instead of calling eglGetDisplay, it looks like we need to use the EGL_KHR_platform_wayland extension and call eglGetPlatformDisplay and pass EGL_DEFAULT_DISPLAY like Glutin does: https://github.com/rust-windowing/glutin/blob/356e6cbe40a999e6afdb999681db6cbf6038da67/glutin/src/api/egl/mod.rs#L305-L331

Can not build on Windows with "sm-raw-window-handle" feature

cargo build --no-default-features --features "sm-raw-window-handle"
results in:

error[E0432]: unresolved import `raw_window_handle::RawWindowHandle::Xlib`
   --> surfman\src\platform\windows\wgl\connection.rs:139:13
    |
139 |         use raw_window_handle::RawWindowHandle::Xlib;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `Xlib` in `RawWindowHandle`

error[E0560]: struct `platform::windows::wgl::surface::NativeWidget` has no field named `window`
   --> surfman\src\platform\windows\wgl\connection.rs:143:17
    |
143 |                 window: handle.window,
    |                 ^^^^^^ `platform::windows::wgl::surface::NativeWidget` does not have this field
    |
    = note: available fields are: `window_handle`

Please publish surfman 0.9.2

Now that #275 is merged and brings rwh 0.6 support, I'd like to update servo webxr & servo/servo.

I don't think this should be released as 0.9.2 because #275 is a breaking change (the "sm-raw-window-handle" feature is now called "sm-raw-window-handle-05", for a start).

To do this without publishing surfman to crates.io, webxr and servo/servo would both have to specify the same commit hash, or frailly depend on the latest code on surfman's master branch (which will surely receive breaking changes)

Blocks:

• servo/webxr#221
• servo/servo#31278

Thank you!

examples `chaos_game` and `threads` not building, winit unresolved imports

In trying to track down a Metal issue with pathfinder, I'm trying to build and run the demos here.
The offscreen demo builds and runs fine, but the chaos_game and threads demos both fail with the same compile errors:

   Compiling surfman v0.4.3 (/Users/.../surfman/surfman)
error[E0432]: unresolved imports `winit::DeviceEvent`, `winit::Event`, `winit::EventsLoop`, `winit::KeyboardInput`, `winit::VirtualKeyCode`
 --> surfman/examples/chaos_game.rs:9:13
  |
9 | use winit::{DeviceEvent, Event, EventsLoop, KeyboardInput, VirtualKeyCode};
  |             ^^^^^^^^^^^  ^^^^^  ^^^^^^^^^^  ^^^^^^^^^^^^^  ^^^^^^^^^^^^^^ no `VirtualKeyCode` in the root
  |             |            |      |           |
  |             |            |      |           no `KeyboardInput` in the root
  |             |            |      no `EventsLoop` in the root
  |             |            no `Event` in the root
  |             no `DeviceEvent` in the root

error[E0432]: unresolved imports `winit::WindowBuilder`, `winit::WindowEvent`
  --> surfman/examples/chaos_game.rs:10:13
   |
10 | use winit::{WindowBuilder, WindowEvent};
   |             ^^^^^^^^^^^^^  ^^^^^^^^^^^ no `WindowEvent` in the root
   |             |
   |             no `WindowBuilder` in the root

This is on macOS 12.1, rustc 1.58.0.

Push 0.1.4 to crates.io

So that servo can pick up the armv7 support.

Clarification of Platform Support

I believe this is similar to #248 in that I'm attempting to use Surfman to support GLES on Linux. According to that issue that is not currently possible without forking the code and adding that support.

My reading of the code suggests this is still the case.

If this is so, I'd suggest clarifying the related README similar to what follows:

The library supports the following platforms:

...

* Windows, with OpenGL ES via Google's ANGLE library.
...

* Android P and up, with OpenGL ES.

not_implemented selection into a feature

Gecko webrender does not use offscreen_gl_context. But it is used by webrender and requests to link to a gl library. It is nice if could remove the link in gecko webrender use case.

Missing CI for sm-raw-window-handle feature

The changes from #250 fixed code that no longer compiled.

preserveDrawingBuffer support

Detach from winit?

Winit releases new versions quite often, at least more often than surfman. And it's a dependency of surfman. So once we start depending on surfman in Gecko, there is a problem of dependency duplication that could arise from winit (e.g. cocoa stuff). Gecko doesn't like duplicated dependencies because Mercurial is bad at vendoring them.

Would it be possible to somehow avoid depending on winit in sm-winit feature? Perhaps, by moving the stable part of winit into a separate crate, or something like that.

update gleam to v0.4

It is necessary for servo/webrender#771.

`CGLCreateContext` fails when creating a context through WebRender from WebGL.

CGLCreateContext fails with error code 10009 when creating via WR from WebGL.

"Invalid share context. Two contexts are a bad match if their pixel formats use different renderers; this can happen if, for example, one format required an accumulation buffer that could be provided only by the software renderer, and the other format did not."

This causes Servo to fallback to a nice and slow alternative.

GlType name is inconsistent

We have GLContext, GLLimits, etc with capital L, and GlType.
cc @sotaroikeda

`threads` example displays a black window on X11

The threads example in master displays a black window on X11. I'm using Arch Linux with a GTX 2080 Ti and the NVIDIA proprietary drivers.

The offscreen example works correctly.

Let me know if you need more details.

Can Create a Mesa Context Without Requiring an X11 or Wayland Connection?

I'm wanting to make an offscreen renderer that is GPU accelerated when available, but can render offscreen on a server VM without X11 or Wayland. If I try to run the offscreen example on a server, even with the --software flag it currently panics because it can't open the Connection.