Unexpected results when not setting draw-order

[dawid2193487]

Describe the bug
Rendering to a surface rather than straight to a window results in incorrect output.

To Reproduce
Here is the code I used, it seems both A and B should produce the same output but it's not the case.
A rendered B rendered

/// ------ A ------ 
let screen = window.screen_size();

window.draw(&Rectangle::new((0,0), screen), Col(Color::BLACK.with_alpha(1.0)));
 
for wall in self.state.walls.iter() {
    wall.draw(window);
}

window.draw(&Rectangle::new((0,0), screen), Img(&self.overlay));

Ok(())

/// ------ B ------
let screen = window.screen_size();
window.draw(&Rectangle::new((0,0), screen), Col(Color::BLACK.with_alpha(1.0))); 
{
    let small_target = Surface::new(720, 480).expect("Creating small target surface failed");

    small_target.render_to(window, |window| {
        for wall in self.state.walls.iter() {
            wall.draw(window);
        }

        Ok(())
    });
    window.draw(&Rectangle::new((0,0), (720, 480)), Img(small_target.image()) );
}

window.draw(&Rectangle::new((0,0), screen), Img(&self.overlay));

Ok(())

ps. I added flush calls at the end later, after taking the screenshot and it seemingly enlarged the output

pps. I ran the program a couple of times and it sometimes produces okay output, but most often bad. I haven't changed the code.

EDIT:
I moved the line

window.draw(&Rectangle::new((0,0), screen), Col(Color::BLACK.with_alpha(1.0))); 

past the render_to(), before putting Surface on the screen, now I get this output. https://i.imgur.com/NnlLuz5.png
Environment and versions (please complete the following information):

• Environment: Windows 10
• Rust compiler version: rustc 1.33.0-nightly (f960f377f 2018-12-24)
• Quicksilver verison: 0.3.4

[ryanisaacg]

I'll look into this and hopefully will have a fix in the next version (expected to be out in the next week or two.)

[ryanisaacg]

@ca1ek Can you provide the structure / data for the walls collection? It would help in reproducing your issue.

[dawid2193487]

@ryanisaacg I mailed you a .tar of the repo

[ryanisaacg]

Having looked into the repo you provided, it seems the draw order bug is a wider problem in the Quicksilver API. If you don't provide a "z" value, Window feels free to rearrange your draw calls in any order it feels fits. For your specific case, a temporary solve is using Window::draw_ex.

In general, the core issue here is unexpected and leaky abstractions with window.flush(), surfaces, and draw order. I've changed the title of the issue to reflect this.

Let me know if setting the Z value manually isn't sufficient!

[dawid2193487]

Well, if I set the z values manually it works alright, though I'm still used to the behavior of just painting over previous calls so I guess I'll just hack it a global variable that increases with each draw and resets to 0 with each frame.

Though, undefined ordering is certainly not what anyone would except coming from a SDL background, so it should at least be noted in the docs.

Also, sorry for the late reply.

[ryanisaacg]

Changing the library API to address this is on my todo list at some point. Lately I've been very busy, and most of my open-source work has been going towards improving libraries Quicksilver depends on.

[ryanisaacg]

This should be solved by the new graphics API! Check it out on the alpha version.