Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:32
    maroider commented #913
  • 02:21
    RpxdYTX commented #913
  • Nov 28 22:27
    atouchet opened #1376
  • Nov 28 09:23

    kchibisov on master

    Update glutin_* dependency requ… (compare)

  • Nov 28 09:23
    kchibisov closed #1367
  • Nov 17 02:42
    dannymcgee commented #1294
  • Nov 04 10:02
    mingxingren opened #1375
  • Oct 31 19:50

    kchibisov on master

    Fix context sharing EGL/GLX mis… (compare)

  • Oct 31 19:50
    kchibisov closed #1353
  • Oct 31 13:17
    maroider labeled #1374
  • Oct 31 13:17
    maroider labeled #1374
  • Oct 31 13:17
    maroider labeled #1374
  • Oct 31 13:15
    mijalk0 opened #1374
  • Oct 31 08:58

    maroider on master

    Fix crates.io badge (#1366) (compare)

  • Oct 31 08:58
    maroider closed #1366
  • Oct 28 18:34
    maroider commented #1373
  • Oct 28 18:33
    maroider labeled #1373
  • Oct 28 18:33
    maroider labeled #1373
  • Oct 28 13:38
    Prollz edited #1373
  • Oct 28 13:37
    Prollz opened #1373
maroider
@maroider:matrix.org
[m]
allright
and the github bot is a bit optimistic about issue numbers
digital
@digital:fairydust.space
[m]
lol
maroider
@maroider:matrix.org
[m]
I thought you had linked to a commit of yours for a hot second there
but no, it was the bot linking to PR number 1 on winit's repository
digital
@digital:fairydust.space
[m]
yeah, I guess I'll go ask in wgpu channels
thanks, you helped me a lot, I appreciate it
1 reply
digital
@digital:fairydust.space
[m]
yeah I put in a sleep, it seems to be a different error
maroider
@maroider:matrix.org
[m]
good to know
I wish you the best of luck in fixing that error
digital
@digital:fairydust.space
[m]
thanks
actually, this feels familiar... nannou-org/nannou#732
but it's not the same issue, I tried it out
maroider
@maroider:matrix.org
[m]
I suppose that your raspberry pi may not support vulkan quite yet
and OpenGL support in wgpu is still a WIP last I checked
digital
@digital:fairydust.space
[m]
might be
Levans
@levans:safaradeg.net
[m]
digital : statically/dynamically linkage of libwayland is completely unrelated to wlroots and drm errors fyi
These are two independent problem
digital
@digital:fairydust.space
[m]
you mean the 00:00:01.505 [backend/drm/drm.c:1594] drmHandleEvent failed error?
Levans
@levans:safaradeg.net
[m]
Yeah, it is related to wlroots/cage, but not to the issue of dlopening libwayland-client.so
digital
@digital:fairydust.space
[m]
ah okay
will be afk for a bit, getting dinner stuff
Sakura
@sakura134:matrix.org
[m]
How does for event in event_sink_back_buffer.drain(..) work in event_loop()? (Since for some reason, it is causing regression in my program. I need to make sure I don't miss anything)
1 reply
My Code
event_loop.run(move |event, _, control_flow| match event {
        Event::WindowEvent { event, .. } => match event {
            WindowEvent::CloseRequested
            | WindowEvent::KeyboardInput {
                input:
                    KeyboardInput {
                        virtual_keycode: Some(VirtualKeyCode::Escape),
                        state: ElementState::Pressed,
                        ..
                    },
                ..
            } => *control_flow = ControlFlow::Exit,
            WindowEvent::KeyboardInput {
                input:
                    KeyboardInput {
                        virtual_keycode: Some(vk),
                        state,
                        ..
                    },
                ..
            } => {}
        },

        Event::MainEventsCleared => { //My code goes here
            }
        }
maroider
@maroider:matrix.org
[m]
Note that I don't really know too much about the Wayland backend
maroider
@maroider:matrix.org
[m]
On a completely different note: I've decided to stop being on various chat platforms for about a week in order to see if I can study properly that way. If anyone really needs me, then I'll be available via email.
maroider
@maroider:matrix.org
[m]
Now that the weekend is upon us, I can definitely say that quitting matrix, discord, and github definitely made it easier to not get distracted, so I'll probably be unresponsive on some days of the week going forward (not that that's too big of an issue on this matrix channel; it's not the most active place).
madsmtm
@madsmtm:matrix.org
[m]
Glad to hear you're approaching a solution that works for you!
maroider
@maroider:matrix.org
[m]
so am I
having permanently open browser tabs for these services like I've done until now just invites distraction, as I'll compulsively check them
josh
@joshyrobot:matrix.org
[m]
how would i go about debugging winit? currently it doesnt spawn any window (with x11 or wayland backend) and the event loop is a constant stream of redraw requests
2 replies
arturkovacs
@arturkovacs:matrix.org
[m]
You could clone the winit repo to get the source, then you should git checkout v0.25.0 or whichever version you are using. Then you should change the dependency in your project from winit = "0.25" to winit = { path = "/path/to/winit"}.
Now you can add printlns or use your preferred debugging tools on your local winit see what the code does
0x6C697370
@michaelmmacleod:matrix.org
[m]

Question about window resize events & scale factors:

I create a window that is 800x600 on a monitor with scale factor 1.0. I then click, drag, and drop the window to a different monitor with scale factor 1.5. Here's the (somewhat filtered) events in the order they get consumed by my event loop:

  1. Resized(size: 800x600) // makes sense, a resize request is sent when a window is shown for the first time
  2. ScaleFactorChanged(factor: 1.5, size: 1200x900) // makes sense, since I moved the window to a different monitor, the scale factor changes
  3. Resized(size: 800x600) // ???
  4. Resized(size: 1200x900) // makes sense, the scale factor changed which resized the window.

Why is event #3 emitted? I haven't changed the window size in the code after event #2. It seems strange to me that both #3 and #4 are sent---shouldn't only #4 be sent?

winit v0.25, Linux/x11

2 replies
Github
@_neb_github:matrix.org
[m]
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
Github
@_neb_github:matrix.org
[m]
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
0x6C697370
@michaelmmacleod:matrix.org
[m]

:point_up: Edit: edit: resolved (see below)

Question about window resize events & scale factors:

I create a window that is 800x600 on a monitor with scale factor 1.0. I then click, drag, and drop the window to a different monitor with scale factor 1.5. Here's the (somewhat filtered) events in the order they get consumed by my event loop:

  1. Resized(size: 800x600) // makes sense, a resize request is sent when a window is shown for the first time
  2. ScaleFactorChanged(factor: 1.5, size: 1200x900) // makes sense, since I moved the window to a different monitor, the scale factor changes
  3. Resized(size: 800x600) // ???
  4. Resized(size: 1200x900) // makes sense, the scale factor changed which resized the window.

Why is event #3 emitted? I haven't changed the window size in the code after event #2. It seems strange to me that both #3 and #4 are sent---shouldn't only #4 be sent?

winit v0.25, Linux/x11

Github
@_neb_github:matrix.org
[m]
rust-windowing/winit#3 : PRs that need to be merged into winit
rust-windowing/winit#2 : Purge OpenGL from cocoa
rust-windowing/winit#4 : Make it compile on Linux
1 reply
arturkovacs
@arturkovacs:matrix.org
[m]
0x6C697370 referred to events in their example using hashmark followed by the event sequence number. The github bot thought these were references to gihub PRs/issues
maroider
@maroider:matrix.org
[m]
although I'm not that familiar with how ScaleFactorChanged works
AidanConnelly
@AidanConnelly
Is it supposed to be obvious how to run futures (core::future::Future, from the futures API) from within the winit event loop? Been bashing my head against this and I can't seem to figure out a way to do it
0x6C697370
@michaelmmacleod:matrix.org
[m]
@AidanConnelly: As far as I know there's no functionality for executing futures in the standard library. You've got to use an executor, like one from the futures crate. block_on is fairly easy to use: https://docs.rs/futures/0.3.17/futures/executor/fn.block_on.html, and there's more complex things there too if you need more control.