servo / surfman Goto Github PK

Accelerated offscreen graphics for WebGL

License: Apache License 2.0

Rust 97.84% Java 1.10% GLSL 1.07%

surfman's Introduction

surfman

surfman is a low-level, cross-platform Rust library for managing surfaces, blocks of image data in GPU memory. Using this library, you can:

Draw to a window (perhaps created with winit) on the CPU.
Render to a window (created via winit or otherwise) with OpenGL.
Render to an off-screen surface with OpenGL.
Use a surface created on one thread as an OpenGL texture on another thread.
Draw to a surface with a platform-specific GPU API like Metal.

surfman forms the low-level graphics infrastructure of the Servo project, where it allows for easy porting of the browser's WebGL and WebXR code to a variety of platforms.

What `surfman` is not

surfman is not a full-featured GPU rendering API. It doesn't attempt to abstract over rendering libraries like OpenGL, Metal, and Direct3D. For that, try gfx-rs.

surfman is also not a windowing solution. It can only render to a window that is already open and needs to be paired with a crate like winit to actually open the window.

Likewise, surfman is not a UI toolkit. For that, see GTK+ and many other libraries. It's possible to use surfman alongside any of these UI toolkits to efficiently integrate GPU rendering into an application, however.

Why `surfman`?

Most of this functionality can be achieved with other libraries, such as glutin and SDL. However, for several use cases you can achieve better performance and/or correctness with surfman. For example:

On multi-GPU systems, games typically want to use the discrete GPU instead of the integrated GPU for better performance, while UI applications want the reverse for better energy consumption. However, most game-oriented OpenGL windowing libraries end up using the discrete GPU on Linux and macOS and the integrated GPU on Windows. On such systems, surfman explicitly allows you to choose which GPU you would like to render with.
OpenGL's share context or share lists feature allows you to share textures across contexts. However, this often exposes driver bugs, and, even if it works, it causes most operations to take mutex locks. Efficient texture sharing requires the use of platform-specific APIs, which surfman abstracts over.
The ANGLE implementation of OpenGL on Windows is not generally thread-safe, so attempts to render on background threads will generally segfault. surfman carefully works around all the safety issues so that the library is safe to use from any thread.
Applications such as emulators and video players that draw to the CPU want to avoid copying pixels as much as possible. Classic APIs for transferring image data like glTexImage2D() and XPutImage() often cause the data to be copied several times. In contrast, surfman allows you to render to the screen with as few copies as feasible—sometimes even zero, depending on the platform.

Platform support

The library supports the following platforms:

Windows, with OpenGL via the native WGL framework.
Windows, with OpenGL via Google's ANGLE library.
macOS, with OpenGL via the native CGL framework.
macOS, with Metal.
Linux/other Unix, with OpenGL on Wayland.
Linux/other Unix, with OpenGL on X11 via GLX.
Android P and up, with OpenGL.
Generic CPU rendering of OpenGL via the OSMesa framework.

Future work

The following features may be added later:

Support for Android Marshmallow, Nougat, and Oreo.
Partial presentation, to allow the OS to composite only the region of the window that has changed.
CPU rendering support on more platforms. (Right now, the CPU rendering features only work on macOS.)
Vulkan support.
Direct3D 11 support on Windows.
YUV surfaces, for software video codecs.
Support for running in a browser with WebAssembly.

License

surfman is licensed under the same terms as Rust itself.

surfman abides by the same code of conduct as Rust itself.

surfman's People

Contributors

Stargazers

Watchers

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.

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).

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

Format the code

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

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)

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

Missing CI for sm-raw-window-handle feature

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

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.

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:

Thank you!

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.

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.

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.

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*.

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.

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

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 {

[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?

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`

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

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.

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

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.

`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.

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

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.

preserveDrawingBuffer support

Push 0.1.4 to crates.io

So that servo can pick up the armv7 support.

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.

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

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.

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.

Test OSMesa back-end

It's right now untested on CI.

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?

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~

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.

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.

update gleam to v0.4

It is necessary for servo/webrender#771.

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.

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

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?

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

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?

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.

`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.

    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.

servo / surfman Goto Github PK

surfman's Introduction

surfman

What surfman is not

Why surfman?

Platform support

Future work

License

surfman's People

Contributors

Stargazers

Watchers

Forkers

surfman's Issues

Recommend Projects

Recommend Topics

Recommend Org

What `surfman` is not

Why `surfman`?