PistonWindow fork

[christolliday]

This copies the piston_window into backend, as discussed here PistonDevelopers/piston_window#170

It replaces the piston_window optional dependency with a piston_window feature.

This also makes the change to the PistonWindow that necessitated the fork, that is, decoupling the default piston event loop. If this is merged I can clean up #831

Hopefully this also enables other future changes to PistonWindow as well. My thoughts are this forked version of PistonWindow can be made more configurable in general, rather than just as simple as possible for the common case.

The new window was originally going to be called ConrodWindow but I agree the prefix shouldn't be necessary, (see PistonDevelopers/piston_window#170) so I just left it as PistonWindow. It is a better description of what it is, although it does duplicate the name in piston_window. I'm hoping that won't be too confusing, but I'm open to alternative names if it is.

[bvssvni]

Please don't duplicate the name. That will be confusing.

[mitchmindtree]

I'd be fine with just Window and putting it in the conrod::backend::piston module? I don't mind if it conflicts with the Window trait as it can be imported as Foo; or used via the module path if necessary (I normally prefer using the module path anyway, i.e. conrod::backend::piston::Window). If we end up deciding to remove the backend module in the future in favour of leaning on piston more again, accessing it as conrod::Window is also fine I think.

[christolliday]

Ok great, I was just about to suggest that, do you think we should keep the piston_window feature, or just fold it in to the piston feature?

[mitchmindtree]

I like the idea of folding it into the piston one 👍

[mitchmindtree]

@christolliday you might need to rebase onto master again now that #851 is merged.

[christolliday]

Hey @mitchmindtree I made those changes, rebased, and also did some refactoring on the new window module, wasn't sure if it made sense to have a separate pull request so I just added it here. Basically it splits out all the gfx related code from the window into a separate module and struct, GfxContext, so that the window itself is as simple as possible. I think it's a pretty clean split, although I'm open to any changes on the way exports are exposed, or imported by the examples.

Also with this simpler window design it could be possible to restore the old API of having the event loop fully integrated into the window, just by creating different window modules for different event loops, with much less duplication. That said I am more in favour of this API of instantiating the event loop (WindowEvents) on it's own and calling it directly, although it is a breaking change.

[mitchmindtree]

@christolliday thanks for this, I'll have a closer look first thing tomorrow!

[mitchmindtree]

@christolliday this all looks fine to me 👍

That said I am more in favour of this API of instantiating the event loop (WindowEvents) on it's own and calling it directly

I agree with this, I'm happy to leave it as it is.

Going to merge! I another PR or two I'd like to land, but hopefully will publish these changes before the end of the day 👍 Thanks again for all this :) PS you might be interested in the performance improvements in #852 if you happen to be using conrod with glium. I'm considering updating a couple of the examples to use that backend as the performance is significantly better and the text rendering works nicely (though I believe the text rendering should work nicely in piston too once we update versions).

[mitchmindtree]

Hmmm I'm just doing some testing after having merged this and it appears this PR has introduced a bug that shows itself during resizing.

For example, to start, the all_widgets example looks like this:

However after resizing it looks like this:

Not sure what could have changed that would cause this, I'll look into it now.

[mitchmindtree]

@christolliday any idea what might be going on or where to look? Does this happen on your machine also? I don't have time to look much closer tonight, but will try to get around to it soon. In the meantime I've opened up #854 for tracking it.