quadrupleslap / scrap Goto Github PK
View Code? Open in Web Editor NEW📸 Screen capture made easy!
Home Page: https://crates.io/crates/scrap
📸 Screen capture made easy!
Home Page: https://crates.io/crates/scrap
Namely, those that don't have DirectX 11.1.
Hi,
I always get error when calling this: Capturer::new(display)
as other os error
It is running as administrator. What am I missing? Is there any specific requirement during compiling? or am I missing something else?
Windows 10 Pro is where I'm trying with Rust 1.52
use scrap::*;
fn main() {
for i in 1..100 {
let display = Display::primary()?;
Capturer::new(display)?;
}
}
Not that anyone would want to initialise the Capturer several times (I stumbled on this by accident) but I think this is caused by this:
After this call returns, the stream is stopped. When the stream stops, its callback is called
with a status of kCGDisplayStreamFrameStatusStopped. You must wait until this callback is
received before releasing the display stream object.
https://github.com/quadrupleslap/scrap/blob/master/src/quartz/capturer.rs#L75
I tried keeping a pointer reference and moving
CFRelease(self.stream);
dispatch_release(self.queue);
in the handler but it still sigsegv
I guess we would need to wait for the handler to be over inside drop
See MSDN's documentation on DXGI_OUTDUPL_DESC
for more information. Right now the library assumes that the buffer is already in system memory, which is probably not the best idea.
I ran the example "screenshot" and got a distorted image with DirectX 12.
By the way, if you can provide me with pointers on how to fix this bug for you, that'd be great. 'scrap' was the fastest screenshotting library for me.
I've noticed in my loop that while I can capture frames at 1ms roughly when I add some more code(SDL texture.update() + canvas.copy() + canvas.present(), vulkano code to create/upload texture and update frame, or even thread sleep for around 16ms) that my screen capture can take as long as 4ms instead.
Presumably something to do with CPU cache being used when the loop is only involving the screen capture, I'm not sure. I thought to try capture some frames first into a vec and then iterate through those in my loop, it reduced the times a little, but for my real-time case wasn't worthwhile after all.
Anyway, capturing frames in a loop didn't seem to play well due to lifetimes, I couldn't seem to move the frame data to store elsewhere for some reason. Here's some solutions I came across:
This managed to do 4 iterations a loop in 13ms and 8 in about 23ms. data_vec is Vec<Vec> declared before the wrapping loop of the codeblock below begins.
// Initially 1st loop is skipped, 2nd loop then fills up data_vec,
// subsequent loops will then only run the 1st loop to update the
// existing data_vec elements avoiding new allocations to_vec() causes
let mut n = 0..8;
for (v, _) in data_vec.iter_mut().zip(&mut n) {
v.clear();
v.extend_from_slice(&scrap.frame().unwrap());
}
for _ in n {
&data_vec.push(scrap.frame().unwrap().to_vec());
}
I found copy_from_slice()
faster than to_vec()
(without iterations, or any other code, took the 1ms operation to 4ms, and copy_from_slice() managed 2ms) probably because of the allocation being avoided. Didn't compare with extend_from_slice()
. Pushing the frame/&[u8] data from scrap.frame() to move it to a vec would be nice, but as stated that didn't seem to be an option requiring a copy/allocation like to_vec()
:(
Any chance an API update could better handle that? Or is the above the best way to go about it?
The following log was printed when I tried to capture from a portrait screen (1080 x 1920):
w: 1080, h: 1920, buffer_len: 14745600
pixels: 3686400, pixels / 1920: 1920
stride:4320
RGB-len:6220800
I have hard coded stride
to 4320 so the final buffer would be the correct length. (The saved image is pure distorted noise nevertheless) It seems that the captured buffer would use a strange 1920x1920 resolution?
Code for reproduce:
fn cap_and_save(file_name: &str) -> () {
let one_second = Duration::new(1, 0);
let one_frame = one_second / 60;
let display = Display::all().expect("Couldn't find any display.");
let second = display
.into_iter()
.nth(1)
.expect("Couldn't find second display.");
let mut capturer = Capturer::new(second).expect("Couldn't begin capture.");
let (w, h) = (capturer.width(), capturer.height());
loop {
// Wait until there's a frame.
let buffer = match capturer.frame() {
Ok(buffer) => buffer,
Err(error) => {
if error.kind() == WouldBlock {
// Keep spinning.
thread::sleep(one_frame);
continue;
} else {
panic!("Error: {}", error);
}
}
};
println!("Captured! Saving...");
// Flip the ARGB image into a RGB image.
let mut bitflipped = Vec::with_capacity(w * h * 4);
//let stride = buffer.len() / h;
let stride = 4320;
println!("w: {}, h: {}, buffer_len: {}", w, h, buffer.len());
println!("pixels: {}, pixels / 1920: {}", buffer.len()/4, (buffer.len() / 4) / 1920);
println!("stride:{}", stride);
for y in 0..h {
for x in 0..w {
let i = stride * y + 4 * x;
bitflipped.extend_from_slice(&[buffer[i + 1], buffer[i + 2], buffer[i + 3]]);
}
}
println!("RGB-len:{}", bitflipped.len());
...
break;
}
Env:
Windows 10, scrap = "0.5"
Hi,
I get an error on Windows 10: Couldn't capture frame.: Error { repr: Kind(ConnectionRefused) }.
When I make a screenshot, what pixel format(RGB, BGR and etc) does my screenshot have?
There is a memory leak in Capturer, at least in the dxgi (Windows) implementation. A simple example:
extern crate scrap;
fn main() {
for i in 0..30 {
open_capturer();
println!("Capturer {:?} opened.", i);
std::thread::sleep_ms(2000);
}
}
fn open_capturer() {
let display = scrap::Display::primary().expect("Couldn't get display.");
let capturer = scrap::Capturer::new(display).expect("Couldn't begin capture");
}
consumes an additional 10mb every 2s, which does not decrease until the program exits.
I am just starting out with rust and this is a library I really want to use but while making a screen recorder I am not able to understand the Frame implementation.
Was just testing this rad library with some sample code and noticed it's ultra reliable when called in a standard console mode, but I wanted the console not in the screenshot so tried wrapping it #![windows_subsystem = "windows"], now 4 out of 5 attempts to call this produces a blank output.
Testing on Windows 10.
`//#![windows_subsystem = "windows"]
extern crate repng;
extern crate scrap;
use scrap::{Capturer, Display};
use std::io::ErrorKind::WouldBlock;
use std::fs::File;
use std::thread;
use std::time::Duration;
fn main() {
let one_second = Duration::new(1, 0);
let one_frame = one_second / 60;
let display = Display::primary().expect("Couldn't find primary display.");
let mut capturer = Capturer::new(display).expect("Couldn't begin capture.");
let (width, height) = (capturer.width(), capturer.height());
loop {
// Wait until there's a frame.
let buffer = match capturer.frame() {
Ok(buffer) => buffer,
Err(error) => {
if error.kind() == WouldBlock {
// Keep spinning.
// println!("Waiting...");
thread::sleep(one_frame);
continue;
} else {
panic!("Error: {}", error);
}
}
};
// println!("Captured! Saving...");
// Flip the ARGB image into a BGRA image.
let mut bitflipped = Vec::with_capacity(width * height * 4);
let stride = buffer.len() / height;
for y in 0..height {
for x in 0..width {
let i = stride * y + 4 * x;
bitflipped.extend_from_slice(&[
buffer[i + 2],
buffer[i + 1],
buffer[i],
255,
]);
}
}
// Save the image.
repng::encode(
File::create("screenshot.png").unwrap(),
width as u32,
height as u32,
&bitflipped,
).unwrap();
// println!("Image saved to `screenshot.png`.");
break;
}
}`
Display::main
in favor of Display::primary
.PixelFormat
because the format is always ARGB32.Display::main
.PixelFormat
.Whenever I try to turn my pc on from sleep mode, the capturer.frame() returns InvalidData. Even if I try to recreate it with the new instance of primary display, it fails miserably each loop iteration. I don't see a reason to this kind of behaviour yet, but it should somehow relate to dxgi::Capturer.
Hi,
I have tried to install your crate with the below commands but neither works because of a missing executable
cargo install scrap
cargo install --git https://github.com/quadrupleslap/scrap.git
error: specified package scrap v0.5.0
has no binaries
$ cargo run
Compiling hbb_common v0.1.0 (C:\Users\1\rustdesk\libs\hbb_common)
Compiling scrap v0.5.0 (C:\Users\1\rustdesk\libs\scrap)
Compiling hyper-rustls v0.23.2
Compiling reqwest v0.11.13
error: failed to run custom build command for scrap v0.5.0 (C:\Users\1\rustdesk\libs\scrap)
Caused by:
process didn't exit successfully: C:\Users\1\rustdesk\target\debug\build\scrap-80d6c6f8afe2291c\build-script-build
(exit code: 101)
--- stdout
cargo:info=x64-windows-static
cargo:rustc-link-lib=static=yuv
cargo:rustc-link-search=C:/Users/1/vcpkg\installed\x64-windows-static\lib
cargo:include=C:/Users/1/vcpkg\installed\x64-windows-static\include
cargo:info=x64-windows-static
cargo:rustc-link-lib=static=vpx
cargo:rustc-link-search=C:/Users/1/vcpkg\installed\x64-windows-static\lib
cargo:include=C:/Users/1/vcpkg\installed\x64-windows-static\include
rerun-if-changed=C:\Users\1\rustdesk\libs\scrap\vpx_ffi.h
rerun-if-changed=C:/Users/1/vcpkg\installed\x64-windows-static\include
--- stderr
thread 'main' panicked at 'called Result::unwrap()
on an Err
value: LexError { span: Span }', C:\Users\1.cargo\registry\src\github.com-1ecc6299db9ec823\bindgen-0.59.2\src\codegen\mod.rs:4577:66
note: run with RUST_BACKTRACE=1
environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
Maybe just put them in the README.md
because they're really important.
In building rustdesk
, I come across this error:
Compiling scrap v0.5.0 (/home/var/ravi/.cache/aur/rustdesk/src/rustdesk-1.1.9/libs/scrap)
Compiling magnum-opus v0.4.0 (https://github.com/open-trade/magnum-opus#3c3d0b86)
error: failed to run custom build command for `scrap v0.5.0 (/home/var/ravi/.cache/aur/rustdesk/src/rustdesk-1.1.9/libs/scrap)`
Caused by:
process didn't exit successfully: `/home/var/ravi/.cache/aur/rustdesk/src/rustdesk-1.1.9/target/release/build/scrap-2136fd8803e9c6e2/build-script-build` (exit status: 101)
--- stderr
thread 'main' panicked at 'Failed to find package: VcpkgNotFound("No vcpkg installation found. Set the VCPKG_ROOT environment variable or run 'vcpkg integrate install'")', libs/scrap/build.rs:7:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: could not find native static library `opus`, perhaps an -L flag is missing?
error: could not compile `magnum-opus` due to previous error
==> ERROR: A failure occurred in build().
So what value for VCPKG_ROOT
?
% cat /usr/bin/vcpkg
#!/bin/sh
export VCPKG_ROOT=/opt/vcpkg
export VCPKG_DOWNLOADS=/var/cache/vcpkg
$VCPKG_ROOT/vcpkg "$@"
So after manually:
export VCPKG_ROOT=/opt/vcpkg
export VCPKG_DOWNLOADS=/var/cache/vcpkg
The output changes to:
Compiling scrap v0.5.0 (/home/var/ravi/.cache/aur/rustdesk/src/rustdesk-1.1.9/libs/scrap)
Caused by:
process didn't exit successfully: `/home/var/ravi/.cache/aur/rustdesk/src/rustdesk-1.1.9/target/release/build/scrap-2136fd8803e9c6e2/build-script-build` (exit status: 101)
--- stderr
thread 'main' panicked at 'Failed to find package: VcpkgInstallation("could not read status file updates dir: No such file or directory (os error 2)")', libs/scrap/build.rs:7:45
About 430 modules of rustdesk
have build just fine so far, so I'm wondering if there is something special going on with scrap
?
Looking at the example code it states there is primary()
and all()
but primary()
seems to capture both my monitor displays? Is that intended?
let display = Display::primary().expect("Couldn't find primary display.");
let mut capturer = Capturer::new(display).expect("Couldn't begin capture.");
let (w, h) = (capturer.width(), capturer.height());
and
/// The primary screen.
pub fn primary() -> io::Result<Display>;
/// All the screens.
pub fn all() -> io::Result<Vec<Display>>;
I try to take the screen on mac os (run on MacBook Pro M1), I follow the sample code here
But the result is
I test in Linux, the code works great.
Do you have any idea what could be going on?
Many mac os laptops have high DPI screens, like Retina. I've created a screenshot capturer using this library, but the captured screenshots are very low resolution. Here's an example:
When I check the resolution of the detected display, it reports 1440x900. However, the resolution is reported to be 2880x1800 in my system information.
I've looked for existing code that gets a high resolution version of the display, but the majority of stuff seems to be Objective-C code with poor documentation.
I'd be happy to work on this, but I don't really know where to start. If you had any ideas about how to implement this or even some documentation that I could look at, I'd love to dive in and try to set it up.
Right now I'm pretty sure that it works, but somebody might want to check that it's actually freeing things at the right time, and not somehow leaking memory or causing undefined behavior. In particular, this file needs to be checked.
When image-rs/image#451 is resolved the example won't need its own buffer anymore.
As far as I know, there is no consensus on a full screen-shooting protocol yet, though.
Both this crate and dxgcap use dxgi, but only later is able to capture fullscreen apps why?
But i find performance of this crate better, any way to make it work with fullscreen apps and games?
This would be pretty cool. :)
let display = Display::primary().unwrap();
let capturer = Capturer::new(display).unwrap();
let (w, h) = (capturer.width(), capturer.height());
often get w=1920,h=1080,but occasionally we get w=4096,h=2160.
Would it be possible to write mutable versions of functions to allow for in-place image editing? For example, the BGRA --> RGBA
in examples/screenshot.rs
could be rewritten as:
for pixel in buffer.chunks_exact_mut(4) {
unsafe { pixel.get_unchecked_mut(0..3).reverse() }
}
Not sure if that's actually better but I'm working on a project that could use scrap if it allowed in-place editing of the screenshot.
I haven't found any bugs like that yet, but there should probably be some kind of rigorous testing to makes sure everything works.
How can I use this in async context?
I'm trying to use it in tauri
framework, when user invoke
function it captures frames in loop and do async task with every capture
but I got the error:
Future cannot be sent between threads safely
within `impl futures::Future<Output = Result<(), std::string::String>>`, the trait `std::marker::Send` is not implemented for `*mut winapi::d3d11::ID3D11DeviceContext
I'm using Capturer::frame()
in a async code, which blocks other code because I had to wait until a Frame
is returned.
I have tried to run such code with smol::unblock()
use scrap::{Capturer as RealCapturer, Display};
pub struct Screenshot {
pub capturer: RealCapturer,
}
impl Screenshot {
pub fn new() -> Result<Self, std::io::Error> {
Ok(Self { capturer: RealCapturer::new(Display::primary()?)? })
}
pub fn capturer_size(&self) -> (usize, usize) {
(self.capturer.width(), self.capturer.height())
}
pub async fn capture(&mut self) -> Result<Vec<u8>, std::io::Error> {
smol::unblock(|| loop {
match self.capturer.frame() {
Ok(frame) => break Ok(frame.to_vec()), // sometimes returns an empty frame
Err(e) if e.kind() == std::io::ErrorKind::WouldBlock => {},
Err(e) => break Err(e),
}
}).await
}
}
but failed as Capture
doesn't implements Send
`*mut winapi::d3d11::ID3D11Device` cannot be sent between threads safely
within `Screenshot`, the trait `std::marker::Send` is not implemented for `*mut winapi::d3d11::ID3D11Device`
required because of the requirements on the impl of `std::marker::Send` for `&mut Screenshot`
1 redundant requirements hidden
required because of the requirements on the impl of `std::marker::Send` for `&mut &mut Screenshot`
required because it appears within the type `[closure@src\screenshot.rs:21:23: 27:10]`
➜ screenrec git:(master) ✗ cargo build --verbose
Fresh scopeguard v0.3.2
Fresh bitflags v0.9.1
Fresh winapi v0.2.8
Fresh inflate v0.2.0
Fresh color_quant v1.0.0
Fresh block v0.1.6
Fresh adler32 v1.0.0
Fresh byteorder v1.0.0
Fresh lazy_static v0.2.8
Fresh num-traits v0.1.39
Fresh lzw v0.10.0
Fresh either v1.1.0
Fresh libc v0.2.24
Fresh scoped_threadpool v0.1.7
Fresh futures v0.1.14
Fresh deflate v0.7.11
Fresh enum_primitive v0.1.1
Fresh num-integer v0.1.34
Fresh gif v0.9.2
Fresh coco v0.1.1
Fresh rand v0.3.15
Fresh num_cpus v1.6.2
Fresh scrap v0.1.2
Fresh num-iter v0.1.33
Fresh num-rational v0.1.38
Fresh rayon-core v1.2.1
Fresh png v0.8.0
Fresh rayon v0.8.1
Fresh jpeg-decoder v0.1.13
Fresh image v0.14.0
Compiling screenrec v0.1.0 (file:///home/maplicant/Documents/devel/Rust/screenrec)
Running `rustc --crate-name screenrec src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=bb09d68be080d72b -C extra-filename=-bb09d68be080d72b --out-dir /home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps -L dependency=/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps --extern scrap=/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libscrap-398b7e6629a87513.rlib --extern image=/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libimage-f078757a33c9159f.rlib`
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/screenrec-bb09d68be080d72b.0.o" "-o" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/screenrec-bb09d68be080d72b" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps" "-L" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libscrap-398b7e6629a87513.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libimage-f078757a33c9159f.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libpng-a114343505cc1d14.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libdeflate-9be50c739d2df728.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libadler32-8ac6aa69a70fa080.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libbitflags-372a95ab4cc479f7.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libnum_rational-87324435ebda7f53.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libnum_iter-446bb564da23085a.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libnum_integer-c604d411e4256fbd.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libenum_primitive-28b7dcc8b8af8311.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libnum_traits-dd33b8bb614ece8e.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libinflate-db65bd44db5037e7.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libjpeg_decoder-95fcd4a98567c777.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/librayon-e16a4c822979dd76.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/librayon_core-e1f4f58f499dad72.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/librand-96181c07164fa9d9.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libnum_cpus-294621ac5c29b238.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/liblibc-0fdc7aea580f4977.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libbyteorder-e5ae63249885046f.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libcoco-a8ca44bf1ad4e17c.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libscopeguard-0cadb91ce555c3f1.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libeither-d5f347904f10bb5c.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/liblazy_static-201baede74b5fff5.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libgif-a1a6ce566018054b.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libcolor_quant-5939ef6b551881a6.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/liblzw-8bea4c513c982b7b.rlib" "/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libscoped_threadpool-88c447763966f498.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-0ab0f38f76e62ecb.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-c00433cc02c7f412.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-4b0076a155ac1be8.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f5a770acdd4a04b8.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-2b8721ba41c3686b.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-3bf84671f6fdb8a8.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-a0c9952b3cbcc63f.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-bc21c9b6dd5a024a.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-b7dee4a73aabc279.rlib" "/home/maplicant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-5f04410eac19d9f6.rlib" "-Wl,-Bdynamic" "-l" "xcb" "-l" "xcb-shm" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"
= note: /usr/bin/ld: cannot find -lxcb
/usr/bin/ld: cannot find -lxcb-shm
collect2: error: ld returned 1 exit status
error: aborting due to previous error(s)
error: Could not compile `screenrec`.
Caused by:
process didn't exit successfully: `rustc --crate-name screenrec src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=bb09d68be080d72b -C extra-filename=-bb09d68be080d72b --out-dir /home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps -L dependency=/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps --extern scrap=/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libscrap-398b7e6629a87513.rlib --extern image=/home/maplicant/Documents/devel/Rust/screenrec/target/debug/deps/libimage-f078757a33c9159f.rlib` (exit code: 101)
I'm really getting sick of these C/Rust interop problems, we should obviously just rewrite XCB
in Rust ;)
Doesn't seem specific to this library, but more with my environment.
Ubuntu 17.04, rustc 1.20.0-nightly (ab5bec255 2017-06-22)
It is my understanding that in order to follow the terms of the MIT license, a license text file that covers the entire project or notices in each file is required.
I am looking specifically at this line of text from the license:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
I believe that only including "MIT" in the Cargo.toml
is not legally binding.
fn Display::name(&self) -> &str;
Hi,
From the api, it was not clear to me how to get a subset of screen.
For example, I want to a bounding box 200x200 px captured at the center of my display.
How should I go about using the api?
Best,
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.