Is it possible to set the initial color used to fill a pixel buffer, or start with the border color?

[Nejat]

Hi,

When you run the minimal-tao example it starts all white in windowed mode, before rendering starts.

However, if you change the example to full screen, most of the screen is the black border color and what seems to be the unsized pixel buffer is all white, before the example starts rendering the moving box.

It would be nice if the buffer matched the border color and even better if you can set an initial startup color.

Is this possible?

Thanks

[parasyte]

This behavior isn't specific to tao. Running the minimal-winit example shows similar behavior (at least on Windows 11). Unless the window provider (tao or winit, etc) gives you some control over the window background color, there isn't much that the pixels crate can do to address this. Looking through docs for both window provider crates, nothing jumps out as a potential solution. Even building the window with Theme::Dark doesn't change the background color.

If you are using Windows, then this discussion is probably relevant: https://stackoverflow.com/questions/69715610/how-to-initialize-the-background-color-of-win32-app-to-something-other-than-whit

Based on an idea in that thread, you can defer visibility of the window pretty easily:

diff --git a/examples/minimal-tao/src/main.rs b/examples/minimal-tao/src/main.rs
index cf88501..8833e92 100644
--- a/examples/minimal-tao/src/main.rs
+++ b/examples/minimal-tao/src/main.rs
@@ -4,7 +4,7 @@
 use log::error;
 use pixels::{Error, Pixels, SurfaceTexture};
 use tao::dpi::LogicalSize;
-use tao::event::{Event, KeyEvent, WindowEvent};
+use tao::event::{Event, KeyEvent, StartCause, WindowEvent};
 use tao::event_loop::{ControlFlow, EventLoop};
 use tao::keyboard::KeyCode;
 use tao::menu::{MenuBar, MenuItem};
@@ -38,6 +38,7 @@ fn main() -> Result<(), Error> {
             .with_menu(menu)
             .with_inner_size(size)
             .with_min_inner_size(size)
+            .with_visible(false)
             .build(&event_loop)
             .unwrap()
     };
@@ -51,6 +52,7 @@ fn main() -> Result<(), Error> {

     event_loop.run(move |event, _, control_flow| {
         match event {
+            Event::NewEvents(StartCause::Init) => window.set_visible(true),
             Event::WindowEvent { event, .. } => match event {
                 // Close events
                 WindowEvent::CloseRequested

This seems to hide the flash of white background in both normal and fullscreen display modes.

One of the side effects of deferring the visibility like this is that it changes the way the window animates. Maybe there is a way to reimplement the animation if you need it. You might be required to use platform-specific libraries to do so.

[Nejat]

First of all, thank you very quick yet very thorough response.

I'm not concerned with the animation, so I ended up with something like this to minimize the impact to windows only.

    cfg_if! {
        if #[cfg(target_os = "windows")] {
            let visibility = false;
        } else {
            let visibility = true;
        }
    }

    let window = {
        let size = LogicalSize::new(width as f64, height as f64);

        WindowBuilder::new()
            .with_title("pxlr")
            .with_inner_size(size)
            .with_min_inner_size(size)
            .with_fullscreen(Some(Fullscreen::Borderless(None)))
            .with_visible(visibility)
            .build(&event_loop).unwrap()
    };

incidentally, testing this out on my Linux setup I found that the minimal-tao example has a very bad flickering issue so I switched to winit. on Pop!Os 22.04 LTS, i7-8550U, Integrated Graphics, system up-to-date

[parasyte]

Seems like a very reasonable way to handle it, given the circumstances. And thanks for the heads up on the flickering issue. I'm glad we have multiple options for choosing a window provider when these kinds of things show up!