pistondevelopers / glutin_window Goto Github PK

View Code? Open in Web Editor NEW

25.0 38.0 40.0 690 KB

A Piston window back-end using the Glutin library

License: MIT License

Rust 100.00%

glutin_window's Introduction

glutin_window

A glutin back-end for the Piston game engine

How to contribute

Installation

To use this as a dependency, add the following code to your Cargo.toml file:

    [dependencies.pistoncore-glutin_window]
    git = "https://github.com/PistonDevelopers/glutin_window"

How to create a window

let mut window: GlutinWindow = WindowSettings::new("Glutin Window", (640, 480))
    .fullscreen(false)
    .vsync(true)
    .build()
    .unwrap();

See the examples for more ways to create a window.

Dependencies

glutin_window's People

Contributors

Stargazers

Watchers

Forkers

bvssvni mitchmindtree xilec milibopp synasius abonander nixes durka jamescleary pierrechevalier83 getynge anthiste boscop andybarron joshpurvis azriel91 canndrew jb55 willglynn jeffparsons ebarnard crazymykl danslocombe 0e4ef622 tdaffin nixpulvis mbrubeck santiagocezar chetic zainlessbrombie lubosmudrak alecamara mario-s shinmili rhettli nathaniel-daniel deltanedas aarchangel64 scarab-games risboo6909

glutin_window's Issues

GlutinWindow needs dependency updates

I think there is a dependency conflict between piston pulling pistoncore-window 0.6.0 and pistoncore-glutin_window pulling pistoncore-window 0.5.0 like with the following errors:
https://gist.github.com/stratact/295bfe6db234948c3795

Set `should_close` by handling event

When rust-windowing/glutin#488 lands, the Close event should be handled to set the should_close flag, instead of checking is_closed.

Sleeping before rendering without polling events leads to error when closing window

Posting this here because I am not certain whether this should be solved in Glutin, through some trick in glutin_window, or change the Piston event loop behavior.

The problem is that the Piston event loop sleeps before rendering, and when closing the window while it sleeps, the OpenGL context gets destroyed. The event loop wakes up, starts rendering, and Gfx panics because it checks the errors.

This can be reproduced by modifying the "window.rs" example in the Glutin repository:

window.rs

fn main() {
    use std::time::Duration;
    use std::thread;

    let mut window = glutin::WindowBuilder::new().build().unwrap();
    window.set_title("A fantastic window!");
    window.set_window_resize_callback(Some(resize_callback as fn(u32, u32)));
    let _ = unsafe { window.make_current() };

    println!("Pixel format of the window: {:?}", window.get_pixel_format());

    let context = support::load(&window);

    'program: loop {
        for event in window.poll_events() {
            // Sleep before rendering to make time to destroy the OpenGL context.
            thread::sleep(Duration::from_millis(200));
            context.draw_frame((0.0, 1.0, 0.0, 1.0));

            println!("{:?}", event);

            match event {
                glutin::Event::Closed => {
                    println!("TEST closed");
                    break 'program;
                }
                _ => ()
            }
            let _ = window.swap_buffers();
        }
    }
}

You also need to check for the error:

support/mod.rs

pub fn draw_frame(&self, color: (f32, f32, f32, f32)) {
        unsafe {
            self.gl.ClearColor(color.0, color.1, color.2, color.3);
            let err = self.gl.GetError();
            if err != 0 {
                println!("ERROR: Invalid framebuffer operation {}", err == gl::INVALID_FRAMEBUFFER_OPERATION);
            }
            self.gl.Clear(gl::COLOR_BUFFER_BIT);

            self.gl.DrawArrays(gl::TRIANGLES, 0, 3);
        }
    }

This will print out:

ERROR: Invalid framebuffer operation true
Closed
TEST closed

There is no way to detect whether the Glutin window has been closed, unless you poll all the events.

Can't detect window close with `wait_event`

Currently, the only way to detect the window has closed is by checking should_close().
No event is emitted by poll_event or wait_event. In the case of wait_event, that means that the application will never receive the close event, unless it continuously checks should_close().

I think changing this requires adding a Close event to Input in pistoncore-input. Is there any special reason a Close event isn't returned right now?

All colors darkened after updating to 0.71.0

I manually created a grayscale gradient from black to white using the following code. Using version 0.70.1 it appeared as expected, however after updating to 0.71.0 it appeared as a quadratic gradient. The same effect also occurs when using full color and images.

Using 0.70.1

Using 0.71.0

![linear-greyscale-0-71-0](https://user-images.githubusercontent.com/44325548/232172513-c09d7213-3280-492d-bf82-052aa5d50bd2.png)

I've uploaded the source code I used to generate these images here

In my troubleshooting so far, this effect is almost exactly an image editing "Multiply" effect, and values of each box are essentially the brightness squared.

Two layers of the above 0.70.1 image merged with photoshop's multiply effect

![70-1--multiply--70-1](https://user-images.githubusercontent.com/44325548/232173723-cd020edd-43b2-4531-a72e-2d5d0eed1f3a.png)

Output vs. Input brightness

![brightness effect](https://user-images.githubusercontent.com/44325548/232174089-e2ecdd95-80e6-4e98-a3c3-5cd17a316c8d.png)

`scale_factor` is not considered in mouse event arguments

piston crate doc mentions mouse events as:

Since some computer screens have higher resolution than others, it is convenient to use two kinds of coordinate systems:

A pixel is a single square on the screen

A point is a unit used by window events and 2D graphics

For example, the mouse cursor position events are measured in points.

But current glutin_window doesn't follow this statement; MouseCursorEvent::mouse_cursor passes a position in pixels to a handler.

One would be able to confirm this with paint example in piston-examples. If you let the scale factor be another value than 1.0 according to this, run the paint example and click on the canvas, you would see a dot plotted at a point not under the mouse cursor. (I confirmed on Gentoo Linux X11 Desktop and display that lets scale_factor return 1.8333333333333333.)

Multisampling doesn't work on linux

Using piston_window = "0.34.0", pistoncore-glutin_window 0.20.0, multisampling works for me on macosx but not on linux (Ubuntu 15.10).

Thread panic in Rust 1.48.0

This very simple project crashes on startup when using Rust 1.48.0 but not 1.47.0: https://github.com/Chetic/rustler

thread 'main' panicked at 'attempted to zero-initialize type `glutin::ContextWrapper<glutin::PossiblyCurrent, glutin::Window>`, which is invalid', C:\Users\cheti\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\mem\mod.rs:622:9
stack backtrace:
   0:     0x7ff6634bea59 - std::backtrace_rs::backtrace::dbghelp::trace
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
   1:     0x7ff6634bea59 - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ff6634bea59 - std::sys_common::backtrace::_print_fmt
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:79
   3:     0x7ff6634bea59 - std::sys_common::backtrace::_print::{{impl}}::fmt
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:58
   4:     0x7ff6634d277b - core::fmt::write
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\fmt\mod.rs:1080
   5:     0x7ff6634bba98 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\io\mod.rs:1516
   6:     0x7ff6634c17d4 - std::sys_common::backtrace::_print
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:61
   7:     0x7ff6634c17d4 - std::sys_common::backtrace::print
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:48
   8:     0x7ff6634c17d4 - std::panicking::default_hook::{{closure}}
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:208
   9:     0x7ff6634c13b8 - std::panicking::default_hook
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:227
  10:     0x7ff6634c208f - std::panicking::rust_panic_with_hook
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:577
  11:     0x7ff6634c1bf5 - std::panicking::begin_panic_handler::{{closure}}
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:484
  12:     0x7ff6634bf33f - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:153
  13:     0x7ff6634c1ba9 - std::panicking::begin_panic_handler
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:483
  14:     0x7ff6634d04a0 - core::panicking::panic_fmt
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\panicking.rs:85
  15:     0x7ff6634d03ec - core::panicking::panic
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\panicking.rs:50
  16:     0x7ff6632f34a7 - core::mem::zeroed
                               at C:\Users\cheti\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\mem\mod.rs:622
  17:     0x7ff6632f34a7 - glutin_window::{{impl}}::make_current
                               at C:\Users\cheti\.cargo\registry\src\github.com-1ecc6299db9ec823\pistoncore-glutin_window-0.67.0\src\lib.rs:539
  18:     0x7ff6632b0d96 - piston_window::PistonWindow<glutin_window::GlutinWindow>::draw_2d<glutin_window::GlutinWindow,input::Event,closure-0,tuple<>>
                               at C:\Users\cheti\.cargo\registry\src\github.com-1ecc6299db9ec823\piston_window-0.116.0\src\lib.rs:286
  19:     0x7ff66326d5df - rustler::main
                               at C:\dev\rustler\src\main.rs:71
  20:     0x7ff66328097b - core::ops::function::FnOnce::call_once<fn(),tuple<>>
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\ops\function.rs:227
  21:     0x7ff66325a4fb - std::sys_common::backtrace::__rust_begin_short_backtrace<fn(),tuple<>>
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\std\src\sys_common\backtrace.rs:137
  22:     0x7ff6632b4661 - std::rt::lang_start::{{closure}}<tuple<>>
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\std\src\rt.rs:66
  23:     0x7ff6634c23d3 - core::ops::function::impls::{{impl}}::call_once
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\ops\function.rs:280
  24:     0x7ff6634c23d3 - std::panicking::try::do_call
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:381
  25:     0x7ff6634c23d3 - std::panicking::try
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:345
  26:     0x7ff6634c23d3 - std::panic::catch_unwind
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panic.rs:382
  27:     0x7ff6634c23d3 - std::rt::lang_start_internal
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\rt.rs:51
  28:     0x7ff6632b4633 - std::rt::lang_start<tuple<>>
                               at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\std\src\rt.rs:65
  29:     0x7ff66326d7e0 - main
  30:     0x7ff6634d8394 - invoke_main
                               at d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  31:     0x7ff6634d8394 - __scrt_common_main_seh
                               at d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  32:     0x7ff8b4747c24 - BaseThreadInitThunk
  33:     0x7ff8b66ed4d1 - RtlUserThreadStart
error: process didn't exit successfully: `target\debug\rustler.exe` (exit code: 101)

Process finished with exit code 101

Could be related to a compatibility change in Rust 1.48.0 (the first one):
https://github.com/rust-lang/rust/blob/1.48.0/RELEASES.md#compatibility-notes
Suspect function in glutin_window:
https://github.com/PistonDevelopers/glutin_window/blob/master/src/lib.rs#L535

Capturing glutin events not supported by piston

There are some event types that glutin supports that are not supported by piston, namely glutin::WindowEvent::DroppedFile and glutin::WindowEvent::HoveredFile. I use piston_window to wrap glutin_window, but it would be nice to have access to these events from PistonWindow::next. Would it be possible to pass these events along to a PistonWindow, perhaps through a Event::Custom?

panic when closing window during render, Windows 10

Hi, I have a program written with Piston/glutin_window that is getting a panic sometimes when I close the window. Here it is:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Error { repr: Os { code: 6, message: "The handle is invalid." } })', ../src/libcore\result.rs:799
stack backtrace:
   0:     0x7ff69262df44 - <std::sync::mpsc::RecvError as core::fmt::Debug>::fmt::h644c369fc7e7b3cf
   1:     0x7ff69262c3f3 - std::rt::lang_start::h538f8960e7644c80
   2:     0x7ff69262cdbd - std::panicking::rust_panic_with_hook::hc303199e04562edf
   3:     0x7ff69262cc56 - std::panicking::begin_panic_fmt::hc321cece241bb2f5
   4:     0x7ff69262cb74 - std::panicking::begin_panic_fmt::hc321cece241bb2f5
   5:     0x7ff69262cb0b - rust_begin_unwind
   6:     0x7ff692635595 - core::panicking::panic_fmt::h27224b181f9f037f
   7:     0x7ff69255ca8b - core::result::unwrap_failed<glutin::ContextError>
                        at C:\bot\slave\stable-dist-rustc-win-msvc-64\build\src\libcore\macros.rs:29
   8:     0x7ff692558bb1 - core::result::Result<(), glutin::ContextError>::unwrap<(),glutin::ContextError>
                        at C:\bot\slave\stable-dist-rustc-win-msvc-64\build\src\libcore\result.rs:737
   9:     0x7ff6925658ea - glutin_window::{{impl}}::make_current
                        at C:\Users\radix\.cargo\registry\src\github.com-1ecc6299db9ec823\pistoncore-glutin_window-0.33.0\src\lib.rs:413
  10:     0x7ff6924bc314 - piston_window::PistonWindow<glutin_window::GlutinWindow>::draw_2d<glutin_window::GlutinWindow,input::event::Event<input::Input>,closure,()>
                        at C:\Users\radix\.cargo\registry\src\github.com-1ecc6299db9ec823\piston_window-0.58.0\src\lib.rs:210
  11:     0x7ff69250b304 - main::App::render
                        at C:\Users\radix\Projects\circles\src\main.rs:69
  12:     0x7ff69250ced6 - main::main
                        at C:\Users\radix\Projects\circles\src\main.rs:320
  13:     0x7ff692630411 - _rust_maybe_catch_panic
  14:     0x7ff69262be2a - std::rt::lang_start::h538f8960e7644c80
  15:     0x7ff69252bc99 - main
  16:     0x7ff69263aa88 - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  17:     0x7ff98e5538e3 - BaseThreadInitThunk
error: process didn't exit successfully: `target\debug\main.exe` (exit code: 101)

I'm not completely sure if this is glutin_window's fault or glutin's fault, but I think glutin_window since that's what I see deepest in the stack (glutin_window -> Result::unwrap). I also don't know if you consider this a bug or not. Probably the best thing would be for me to handle the window-close event in my game loop and cleanly shut down, though I haven't figured out how to do that yet.

Exclude title bar from size of window

See PistonDevelopers/piston-examples#184

The title bar should be excluded from the size.

No `should_close` method on `glutin::window::Window`

It must have been moved or replaced, will look into it now.

Here's the error:

src/lib.rs:144:21: 144:35 error: type `glutin::window::Window` does not implement any method in scope named `should_close`
src/lib.rs:144         self.window.should_close() || self.should_close

Coordinate system is messed up in 0.45.2

A square drawn at (0, 400) appears differently in 0.45.1 and 0.45.2.

0.45.1:

0.45.2:

https://gist.github.com/0e4ef622/085fcd4e0cb1b51e431b113b48474723

However, it seems that when you define the y coordinate relative to the bottom of the window (height - y) it is drawn correctly. The converse is true when using the x-coordinate (works normally, but width - x doesn't).

This only seems to occur on HiDPI displays, which would make sense since the only changes between 0.45.1 and 0.45.2 have to do with HiDPI scaling.

Enable Travis CI

Need a .travis.yml

thread '<main>' has overflowed its stack

When trying to build it I get this error:

thread '<main>' has overflowed its stack
Illegal instruction: 4

`eglCreateWindowSurface` fails after updating to android 10

If I run the following code when running on android using cargo apk:

let window: GlutinWindow = WindowSettings::new(
                "rust app", (200.0, 200.0)
            )
            .fullscreen(true)
            .graphics_api(OpenGL::V2_1)
            .build()
            .unwrap();

Logcat shows the following errors:

BufferQueueProducer: [com.optimistic_peach.trees/android.app.NativeActivity#0] connect: already connected (cur=1 req=1)
libEGL  : eglCreateWindowSurface: native_window_api_connect (win=0x762d44c010) failed (0xffffffea) (already connected to another API?)
libEGL  : eglCreateWindowSurfaceTmpl:729 error 3003 (EGL_BAD_ALLOC)
RustAndroidGlueStdouterr: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: OsError("eglCreateWindowSurface failed")', src/libcore/result.rs:1084:5

Full logcat output around this:

threaded_app: WindowFocusChanged: 0x76c432bd00 -- 1
Adreno  : QUALCOMM build                   : bc00834, I609ab310b2
Adreno  : Build Date                       : 04/11/19
Adreno  : OpenGL ES Shader Compiler Version: EV031.26.07.00
Adreno  : Local Branch                     :
Adreno  : Remote Branch                    :
Adreno  : Remote Branch                    :
Adreno  : Reconstruct Branch               :
Adreno  : Build Config                     : S L 8.0.6 AArch64
ActivityTaskManager: Displayed com.optimistic_peach.trees/android.app.NativeActivity: +107ms
Adreno  : PFP: 0x005ff110, ME: 0x005ff066
BufferQueueProducer: [com.optimistic_peach.trees/android.app.NativeActivity#0] connect: already connected (cur=1 req=1)
libEGL  : eglCreateWindowSurface: native_window_api_connect (win=0x762d44c010) failed (0xffffffea) (already connected to another API?)
libEGL  : eglCreateWindowSurfaceTmpl:729 error 3003 (EGL_BAD_ALLOC)
RustAndroidGlueStdouterr: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: OsError("eglCreateWindowSurface failed")', src/libcore/result.rs:1084:5
RustAndroidGlueStdouterr: stack backtrace:
libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 6339 (tic_peach.trees), pid 6314 (tic_peach.trees)
[email protected]: LAUNCH: 0
crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
/system/bin/tombstoned: received crash request for pid 6339
crash_dump64: performing dump of process 6314 (target tid = 6339)
DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
DEBUG   : Build fingerprint: 'google/walleye/walleye:10/QP1A.190711.019/5790879:user/release-keys'
DEBUG   : Revision: 'MP1'
DEBUG   : ABI: 'arm64'
DEBUG   : Timestamp: 2019-10-05 13:24:00-0400
DEBUG   : pid: 6314, tid: 6339, name: tic_peach.trees  >>> com.optimistic_peach.trees <<<
DEBUG   : uid: 10002
DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
DEBUG   :     x0  0000000000000000  x1  00000000000018c3  x2  0000000000000006  x3  00000075d8769ff0
DEBUG   :     x4  000000762ed91238  x5  000000762ed91238  x6  000000762ed91238  x7  000000762ed91000
DEBUG   :     x8  00000000000000f0  x9  00000076c399a4e0  x10 0000000000000000  x11 0000000000000001
DEBUG   :     x12 0000000000000000  x13 0000000000000000  x14 ffffffffffffffff  x15 0000000000000045
DEBUG   :     x16 00000076c3a668c0  x17 00000076c3a44060  x18 00000075d855a000  x19 00000000000000ac
DEBUG   :     x20 00000000000018aa  x21 00000000000000b2  x22 00000000000018c3  x23 00000000ffffffff
DEBUG   :     x24 00000075d876b260  x25 0000000000000005  x26 0000000000000001  x27 00000000000fd000
DEBUG   :     x28 0000007fff11f440  x29 00000075d876a0a0
DEBUG   :     sp  00000075d8769fd0  lr  00000076c39f8170  pc  00000076c39f81a0
DEBUG   :
DEBUG   : backtrace:
DEBUG   :       #00 pc 00000000000821a0  /apex/com.android.runtime/lib64/bionic/libc.so (abort+176) (BuildId: b58d049709674405423a8d8de1a37f56)
DEBUG   :       #01 pc 00000000000bc844  /data/app/com.optimistic_peach.trees-tKVaZx-PR2FlzJuAoEYdjQ==/lib/arm64/libtrees.so
DEBUG   :       #02 pc 00000000000bd08c  /data/app/com.optimistic_peach.trees-tKVaZx-PR2FlzJuAoEYdjQ==/lib/arm64/libtrees.so
DEBUG   :       #03 pc 00000000000a5c6c  /data/app/com.optimistic_peach.trees-tKVaZx-PR2FlzJuAoEYdjQ==/lib/arm64/libtrees.so
ActivityTaskManager:   Force finishing activity com.optimistic_peach.trees/android.app.NativeActivity
/system/bin/tombstoned: Tombstone written to: /data/tombstones/tombstone_03
DropBoxManagerService: add tag=data_app_native_crash isTagEnabled=true flags=0x2
threaded_app: Pause: 0x76c432bd00
threaded_app: activityState=13
BootReceiver: Copying /data/tombstones/tombstone_03 to DropBox (SYSTEM_TOMBSTONE)
ActivityManager: Showing crash dialog for package com.optimistic_peach.trees u0
DropBoxManagerService: add tag=SYSTEM_TOMBSTONE isTagEnabled=true flags=0x2
BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver
threaded_app: WindowFocusChanged: 0x76c432bd00 -- 0

This happens on similar apps which try to initialize a window using glutin.

Note that this is happening on an android 10 device, where it used to work on android pie. (IE the update broke it 😞 )

Build fails on Piston v0.23 due to missing implementations

I have already begun work on this issue to resolve it, I'm adding it to the issue tracker in order to track progress on the fix.

Unknown keys with valid scan codes are not handled.

I am working on a german keyboard and want to capture key events of the german umlaut ü.
The following lines of code prevent this:

glutin_window/src/lib.rs

Line 301 in c9b89f3

virtual_keycode: Some(key), scancode, ..

glutin_window/src/lib.rs

Line 319 in c9b89f3

virtual_keycode: Some(key), scancode, ..

Here, in both cases, a valid virtual key code is required for the event to be fired (Some(key)). If this requirement is omitted (tested localy), an input event for the piston library can be thrown (of course with an unknown key, but valid scancode). This allows the user to handle previous unhandable key inputs.

If a change in that direction is desired, I can provide a pull request implementig this feature.

Allow use of opengles

Use GlRequest::GlThenGles rather than using Specific:
This would allow people to use opengles with glutin_window (Which I have done) without having to modify a local clone.
change this:

.with_gl(GlRequest::Specific(Api::OpenGl, (major as u8, minor as u8)))

To something more like this:

.with_gl(GlRequest::GlThenGles {
    opengl_version: (major as u8, minor as u8),
    opengles_version: (major as u8, minor as u8),
})

It doesn't matter if the user chooses opengl or opengles, because this would support both!

Panic when creating basic fullscreen window

Panic when creating a simple fullscreen window

Tested using a simple code in an empty project to isolate :

use piston_window::{PistonWindow, WindowSettings};

fn main() {
    let window: PistonWindow = WindowSettings::new("aaa", [1920, 1080])
        .fullscreen(true)
        .build()
        .unwrap();
}

Result :

I managed to find where both of the event loops were created :

First : here at the beginning of the creation of the GlutinWindow
Permalink

And here in the window_builder_from_settings function
Permalink

The if check explains why it doesn't happen when using non fullscreen window

No mouse events in "capture_cursor" mode.

Ubuntu Linux x86, xfce4.

If window.set_capture_cursor(true) is called then there are no MouseCursorEvent or MouseRelativeEvent events generated in event loop and cursor stays visible.

No such issue with sdl2_window.

Possibly related to #62.

Make OpenGL initialization default Cargo feature flag

See old discussion here PistonDevelopers/window#56.

At some point the in the future I expect most libraries to be written for either Gfx or Vulkan, so OpenGL initialization will not be needed.

Implement `CaptureCursor`

Glutin has now support for grabbing the cursor.

http://tomaka.github.io/glutin/glutin/enum.CursorState.html#variant.Grab

Panic when polling event in rust 1.48.0 in piston rotating box example

Using this example: https://github.com/PistonDevelopers/Piston-Tutorials/tree/master/getting-started

I get the following stack trace when mousing over the window:

thread 'main' panicked at 'attempted to leave type `platform::platform::x11::util::input::PointerState` uninitialized, which is invalid', /home/USER/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:658:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
   2: core::panicking::panic
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:50
   3: core::mem::uninitialized
             at /home/USER/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:658
   4: winit::platform::platform::x11::util::input::<impl winit::platform::platform::x11::xdisplay::XConnection>::query_pointer
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.5/src/platform/linux/x11/util/input.rs:94
   5: winit::platform::platform::x11::EventsLoop::process_event
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.5/src/platform/linux/x11/mod.rs:956
   6: winit::platform::platform::x11::EventsLoop::poll_events
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.5/src/platform/linux/x11/mod.rs:270
   7: winit::platform::platform::EventsLoop::poll_events
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.5/src/platform/linux/mod.rs:522
   8: winit::EventsLoop::poll_events
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.5/src/lib.rs:277
   9: glutin_window::GlutinWindow::poll_event
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/pistoncore-glutin_window-0.67.2/src/lib.rs:231
  10: <glutin_window::GlutinWindow as window::Window>::poll_event
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/pistoncore-glutin_window-0.67.2/src/lib.rs:476
  11: event_loop::Events::next
             at /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/pistoncore-event_loop-0.52.0/src/lib.rs:253
  12: PROJECT::main
             at ./src/main.rs:67
  13: core::ops::function::FnOnce::call_once
             at /home/USER/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227

I updated the dependencies to look like this:

[dependencies]
piston = "0.52.1"
piston2d-graphics = "0.39.0"
pistoncore-glutin_window = "0.67.2"
piston2d-opengl_graphics = "0.76.0"

The issue does not occur with rust 1.47.0

Publish on crates.io

Add patches and test features from piston v0.23

~~resizable~~ (not supported on OSX (blocked by rust-windowing/glutin#812)
decorated
~~controllers~~ (not supported)

glutin's `LineDelta` and `MouseDelta` are being fed to the same `MouseScroll` event - we should handle this properly.

This is the case as of #66 .

I figured we could leave it this way for now as some support for the event is better than none at all, as long as we track the issue and address it sometime soon.

I see two possible approaches to this:

Somehow test both LineDelta and PixelDelta side-by-side and translate LineDelta to a reasonable pixel value, so that both may continue to be translated to the MouseScroll event with better behaviour.
Add a LineDelta event to the input events in piston.

Originally I thought 2. might be the safest option, however it would be a pain for users to have to handle both kinds of events, and piston is about exposing a nice simple API. If we can manage to do 1. I think that would be nicest, but I'm unsure about the feasibility of this, or whether or not we can make the behaviour consistent across platforms.

@bvssvni thoughts?

A lot of mouse input seems to cause poll_event to return None when it should still have events for that frame

My best guess is that it's caused by this line:
https://github.com/PistonDevelopers/glutin_window/blob/master/src/lib.rs#L378

And that some event is being raised in glutin that's not being handled, causing None to be returned, which will be interpreted as no more events being left even if there still are. The result of this is that game input will lag a lot even if framerate is smooth.

Cursor events are not created if no buttton are pressed

Add fallback to no samples when samples is not supported

Could use the same technique that sdl2_window uses https://github.com/PistonDevelopers/sdl2_window/blob/master/src/lib.rs#L86-L97

Building a window results in an "explicit panic" on Windows

This is happening both in my own code and when running the examples.

thread 'main' panicked at 'explicit panic', C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.7.3\src\platform\windows\window.rs:160
stack backtrace:
   0: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94
   1: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:354
   2: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:371
   3: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:549
   4: std::panicking::begin_panic<&str>
             at C:\projects\rust\src\libstd\panicking.rs:511
   5: winit::platform::platform::window::Window::platform_window
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.7.3\src\platform\windows\window.rs:160
   6: winit::Window::platform_window
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\winit-0.7.3\src\window.rs:264
   7: glutin::platform::platform::context::Context::new
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\glutin-0.9.0\src\platform\windows\context.rs:51
   8: glutin::platform::platform::Context::new
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\glutin-0.9.0\src\platform\windows\mod.rs:69
   9: glutin::GlWindow::new
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\glutin-0.9.0\src\lib.rs:322
  10: glutin_window::GlutinWindow::new
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\pistoncore-glutin_window-0.38.0\src\lib.rs:102
  11: glutin_window::{{impl}}::build_from_window_settings
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\pistoncore-glutin_window-0.38.0\src\lib.rs:399
  12: window::WindowSettings::build<glutin_window::GlutinWindow>
             at C:\Users\Layl\.cargo\registry\src\github.com-1ecc6299db9ec823\pistoncore-window-0.27.0\src\lib.rs:387
  13: calcium_rendering_static::gfx_opengl::{{impl}}::window
             at C:\Users\Layl\Desktop\DamageReport\libraries\rendering\calcium-rendering-static\src\gfx_opengl.rs:38
  14: carpenter::runtime::{{impl}}::run<calcium_rendering_static::gfx_opengl::GfxOpenGlInitializer>
             at .\src\runtime.rs:25
  15: calcium_rendering_static::runtime::run_runtime<carpenter::runtime::StaticRuntime>
             at C:\Users\Layl\Desktop\DamageReport\libraries\rendering\calcium-rendering-static\src\runtime.rs:10
  16: carpenter::run_game
             at .\src\main.rs:52
  17: carpenter::main
             at .\src\main.rs:32
  18: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:98
  19: std::rt::lang_start
             at C:\projects\rust\src\libstd\rt.rs:51
  20: main
  21: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  22: BaseThreadInitThunk
error: process didn't exit successfully: `target\debug\carpenter.exe` (exit code: 101)

Add constructor for existing Glutin window

Currently GlutinWindow can only be constructed from WindowSettings.

Stack overflow in event handling

Occasionally when I launch my application I get a stack overflow. I'm not sure the best way to debug this but the call stack looks like

GlutinWindow::poll_event()
GlutinWindow::handle_event()
GlutinWindow::poll_event()
GlutinWindow::handle_event()
...

My main loop is currently just

let window: GliumWindow = WindowSettings::new("test", [600, 400])
    .exit_on_esc(true)
    .opengl(GL)
    .build()?;
let g2d = Glium2d::new(OpenGL::V3_2, &win);

while let Some(event) = window.next() {
    if let Some(args) = event.render_args() {
        render(gs, args);
    }
    if let Some(args) = event.update_args() {
        update(gs, args);
    }
}

The overflow seems to always happen before any render or update events are actually passed to the main loop.

Scaling issue in 0.48

A window in a HiDPI display seems to scale incorrectly. Moving the window to a standard dpi display causes the window to resize and scale correctly, but it's never right on the HiDPI display. This wasn't really an issue in 0.47 since the window didn't try to resize/rescale when moved between monitors that have different DPI's.

On the HiDPI display (incorrect).

On the standard dpi display (correct).

code

I am running Arch Linux and using the i3 window manager.

$ uname -a
Linux anpotato 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux

Possibly related to rust-windowing/glutin#1068

Resize events aren't delivered on OS X

Here's the relevant issue in glutin. I've only confirmed this on OS X 10.10.

The reason for this seems to be that cocoa (via glutin) requires that the user declares a resize_callback for resizing the window, rather than emitting an event as for all other events.

Events are blocked during resize on OS X within cocoa itself. Cocoa also requires that GL rendering occurs on the main thread (at least I'm pretty sure). I'm unsure whether or not events could be polled from a thread other than the main thread. Either way, any multi-threaded solutions are probably too heavy-weight for this lib or glutin.

For now, I guess we could have a special case for OS X where we create our own Resize events by comparing window sizes as @bvssvni suggests here, however this will only provide the event after the mouse is released and the event loop is unblocked, meaning that we still won't have live Resize or Render events during resizing.

I don't have any great solutions for this yet, just thought I'd post an issue to keep track.

Upgrade to glutin 0.2.0

Crash creating window

I'm trying to run the little game rocket, but it crashes on start. Looks like the problem is creating the glutin window:

$ RUST_BACKTRACE=1 ./rocket                                                                                                         
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: OsError("glx::ChooseFBConfig failed")', src/libcore/result.rs:731
stack backtrace:
   1:     0x7f1d289d713e - sys::backtrace::write::h038220f50279f177vus
   2:     0x7f1d289da505 - panicking::on_panic::h71219c6695575a6bpgx
   3:     0x7f1d289d273e - rt::unwind::begin_unwind_inner::h82aba8beb356b6583Vw
   4:     0x7f1d289d2cfc - rt::unwind::begin_unwind_fmt::h39b470f67c9e92b29Uw
   5:     0x7f1d289d9ef6 - rust_begin_unwind
   6:     0x7f1d28a0cbc4 - panicking::panic_fmt::hc9237b7ecab48700neC
   7:     0x7f1d28811d21 - result::Result<T, E>::unwrap::h2411068402462984045
                        at src/libcore/macros.rs:28
   8:     0x7f1d2880cd8f - GlutinWindow::new::ha1e3edbd4f8b8ccaKaa
                        at /home/simendsjo/.cargo/registry/src/github.com-0a35038f75765ae4/pistoncore-glutin_window-0.4.0/src/lib.rs:61
   9:     0x7f1d28881c0c - GlutinWindow.From<WindowSettings>::from::h6dee4da3f2b294f2hga
                        at /home/simendsjo/.cargo/registry/src/github.com-0a35038f75765ae4/pistoncore-glutin_window-0.4.0/src/lib.rs:127
  10:     0x7f1d2880240c - convert::T.Into<U>::into::h17979526882165784022
                        at src/libcore/convert.rs:152
  11:     0x7f1d28801e1e - main::h0fd56d4a74d57dd1lTa
                        at src/main.rs:27
  12:     0x7f1d289df368 - rust_try_inner
  13:     0x7f1d289df355 - rust_try
  14:     0x7f1d289dc038 - rt::lang_start::h725b432f757180fdmbx
  15:     0x7f1d2880c65b - main
  16:     0x7f1d27d5378f - __libc_start_main
  17:     0x7f1d287ded48 - _start
  18:                0x0 - <unknown>

The offending unwrap seems to be in line 61.
I don't know any rust, so looking at the WindowBuilder in glutin doesn't give me any hints. Not sure if this is the right place to put this issue or if glutin or some other library would be the correct place.

I'm guessing I might be missing some system libraries, but I have no idea what.

$ pacaur -Ss freetype | grep installed
extra/freetype2 2.6-1 [installed]
extra/libxft 2.3.2-1 [installed]
multilib/lib32-freetype2 2.6-1 [installed]
multilib/lib32-libxft 2.3.2-1 [installed]

$ pacaur -Ss fontconfig | grep installed
extra/fontconfig 2.11.1-1 [installed]
multilib/lib32-fontconfig 2.11.1-1 [installed]

Any idea what I'm missing?

Panicked Ubuntu 14.04

Thread panicked when running example window_builder. Failed to get root window {xError {description:"GLXBadFBConfig", error code:181, request_code:156, minor_code:34}
Running on Ubuntu 14.04.

I could run the example in the glutin repo.

fullscreen take size from setting

When I create a window with those settings :

WindowSettings::new("Glutin Window", (640, 480))
    .fullscreen(true)

The window is fullscreen but in the resolution 640x480. Is this the correct behavior ? I would have preferred being in the default resolution of the screen.

If this is a bug then the correction would be:

fn builder_from_settings(settings: &WindowSettings) -> glutin::WindowBuilder {
    let opengl = settings.get_maybe_opengl().unwrap_or(OpenGL::V3_2);
    let (major, minor) = opengl.get_major_minor();
    let size = settings.get_size();
    let mut builder = glutin::WindowBuilder::new()
        //.with_dimensions(size.width, size.height) // <---- deleted
        .with_decorations(settings.get_decorated())
        .with_multitouch()
        .with_gl(GlRequest::Specific(Api::OpenGl, (major as u8, minor as u8)))
        .with_title(settings.get_title())
        .with_srgb(Some(settings.get_srgb()));
    let samples = settings.get_samples();
    if settings.get_fullscreen() {
        builder = builder.with_fullscreen(glutin::get_primary_monitor());
    } else {
        builder = builder.with_dimensions(size.width, size.height); // <---- added
    }
    if settings.get_vsync() {
        builder = builder.with_vsync();
    }
    if samples != 0 {
        builder = builder.with_multisampling(samples as u16);
    }
    builder
}

glutin mousewheel event refactored, cannot compile glutin_window

Glutin was recently updated and MouseWheel was changed:
https://github.com/tomaka/glutin/blob/119bd6393f5f3b8e1510ba6ab3281c8fb387449f/src/events.rs#L32
https://github.com/PistonDevelopers/glutin_window/blob/master/src/lib.rs#L117

Compiling pistoncore-glutin_window v0.0.8 (https://github.com/PistonDevelopers/glutin_window.git#72be8454)
C:\Users\Chris\AppData\Roaming\.cargo\git\checkouts\glutin_window-23cfea1c052c5d5d\master\src/lib.rs:117:18: 117:34 error: this pattern has 1 field, but the corresponding variant has 2 fields [E0023]
C:\Users\Chris\AppData\Roaming\.cargo\git\checkouts\glutin_window-23cfea1c052c5d5d\master\src/lib.rs:117             Some(E::MouseWheel(y)) =>
                                                                                                                          ^~~~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `pistoncore-glutin_window`.

I don't have a chance to pr this, but wanted to give a heads up!

Thanks

Upgrade to latest Rust

Needs update the the new design.

Suggestion: Don't use `gl::load_with`, use `get_proc_address` instead.

@tomaka suggested this in irc

wait, glutin_window calls gl::load_with? and piston uses the same "gl" static objects, hoping that it doesn't mismatch?

... ideally you'd expose get_proc_address and then call it in the code that actually manipulates opengl

plus, the global generator is unsafe on windows, but that's usually ignored by people

panicked at 'glx::MakeCurrent failed'

I got this when trying to run the getting-started in https://github.com/PistonDevelopers/Piston-Tutorials. More details are here: PistonDevelopers/Piston-Tutorials#144

I was able to fix this by using the newest version of glutin from https://github.com/tomaka/glutin as the dependency in which they fixed the issue a couple days ago.

So I guess one would have to wait for the glutin guys to release a new version to crates and then update the dependency accordingly (or just always use the latest version?).