rust-windowing / winit-blit Goto Github PK

The goal of this crate is to have a quick-and-dirty way to throw pixels into a buffer and display them on a window without a significant number of dependencies. Potentially, we'll be able to use this in the Winit examples to clear the screen quickly and get windows showing up with Wayland, but that would require that this work on all the platforms Winit supports.

@vbogaevsky @murarth @vberger @ryanisaacg @mtak- @goddessfreya - would any of you be able to throw together an implementation for the platform you've worked on in Winit? It's totally fine if you're unable or uninterested in working on this, and I have no desire to thrust work onto any of you that you don't want to do. However, you're the people I know I can ping, which seems like a good place to start for getting movement on this crate.

Anyhow, assorted implementation details:

• I have no idea if the current public API will work on all platforms. There's a good chance it won't, but figuring that out will be part of the design process.
• This crate doesn't depend on Winit directly - instead, it depends on raw-window-handle. That works fine on Windows, but there may be some friction on other platforms - particularly X11, which uses a #[doc(hidden)] API to load up Winit's X11 bindings. We should be able to resolve that problem by moving the X11-bindings-loading code into a separate crate that creates a lazy_static bindings object, which both Winit and winit-blit can depend upon.
  • That X11 work will be necessary for decoupling Glutin from Winit, which we should do in the long term. Getting this crate working should help lay the groundwork for figuring out how to do that.
• Ideally, this shouldn't be too complex to implement for the various platforms - the Windows implementation is about 250 lines, and the majority of that code is API boilerplate that can be copied to other platforms.

Let me know if there are any questions. Thanks!

I think it should be documented which color space the blitted pixels must be in. I'm assuming it's sRGB, but it should be explicitly mentioned.

Almost the crate I was looking for. Thanks a lot for (almost) publishing it. Does exactly what I needed it to do, but needs a bit of polish.

I noticed that it leaks GDI resources, and doesn't properly clean up the device contexts it uses. Both issues can be solved with little effort, and should really be considered in face of a programming language that puts so much emphasis on ownership.

I've implemented a test to verify the GDI leak, but didn't feel like pushing a pull request onto you. If you want to incorporate the test (as well as a fix), I'll happily prepare a pull request.

In PixelBuffer::blit_rect the call to GetDC isn't matched with a call to ReleaseDC to free the GDI resources allocated by the system.

The issue can be observed by running either example, setting up Task Manager to display "GDI objects" from the "Details" tab, and resizing the example window. The GDI object count will continuously grow.

I have implemented both a test to observe the leak as well as a fix. Let me know if you want me to create a PR to merge the changes into this repository.

P.S.: There was another issue in blit_rect, where the device context wasn't restored to its initial state prior to releasing control over it. While I fixed that, too, I wasn't able to come up with a test for that particular issue.