Actual Windows window doesn't match terminal screen size with SwingTerminal

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new CursesLikeAPI(new SwingTerminal)
2. Specify the width and height as 80 and 25 respectively
3. Draw a character on all possible squares (try something like '#')

Expected output: the window matches exactly the drawable region.

Actual: there's a huge black area under the last row. If I increase the number 
of rows to 42, there's one empty row. Adding more rows either causes the first 
row to be shifted off-screen, or causes everything to shrink, revealing even 
more black space around the drawn-on area.

This is with the latest Blacken on Windows 8. 

Original issue reported on code.google.com by alibhai....@gmail.com on 21 Nov 2013 at 7:07

[GoogleCodeExporter]

I tried this on a different device (laptop). In that case, the extra space 
appeared on the right-hand side.

Ideally, the window (since it knows the screen size, number of rows, and number 
of columns), should create something perfectly-fitting, with whatever aspect 
ratio or zoom it decides to use.

It seems like it's already picking the correct font size; it just leaves the 
window with extra white-space on one side.

Original comment by alibhai....@gmail.com on 24 Nov 2013 at 10:09

[GoogleCodeExporter]

Hmm... These were both Windows 8 machines?

The requested size is supposed to just be a required minimum. It is supposed to 
expand out in whatever direction is available.

What happens when you try to drag a corner to make the window larger/smaller? 
Does that correct things? The logic for resizing is different than the logic 
for the initial sizing. (Far simpler, actually.)

This was with the latest stable or with the trunk version? (Or an older 
version?)

Original comment by yam...@gmail.com on 28 Nov 2013 at 10:12

[GoogleCodeExporter]

The PC was Windows 8; the laptop Windows 7.

I actually found a much worse bug: Blacken does not display all the characters, 
under certain conditions.

- Create a window; specify 80x35 as the size
- Loop and put "." (floor) in every character, and "#" (walls) at the perimeter
- Add a character "@" which moves to your keyboard commands

The bug I saw was "I can walk through the walls on the RHS." It turns out the 
window, which had this "dead" black space at the bottom, was drawing the RHS 
walls at an X of 65-70. Resizing makes the walls move (the room is getting 
bigger?!), until I can eventually stretch it long enough to see the real 
locations.

A friend of mine tried this on his PC, and saw the same behaviour, but with the 
bottm tiles instead of the side tiles.

Other than this, resizing (scaling up or down) seems to work correctly. There 
is a "bug" where you always have at least one row of "dead space" below your 
screen; if you resize it out, everything draws in really weird locations (like 
seeing plus-shaped wall intersections near the room corners.

All this was done via the latest version from Maven, via Gradle. Because of the 
moving-walls issue, I moved to a different library. If you want, you can grab 
the Blacken-era version of my code and try it for yourself.

GitHub repo for the last revision with Blacken: 
https://github.com/deengames/Freedom/tree/d2f6eeb6b80834fd97a167c7e2deffdfe58159
aa

Original comment by alibhai....@gmail.com on 28 Nov 2013 at 2:19

[GoogleCodeExporter]

I would still like this fixed. Blacken has a lot more potential, despite these 
issues.

Original comment by alibhai....@gmail.com on 28 Nov 2013 at 6:03