Re: XBoard 4.7.3: Full board textures + maximize window

Sebastian Pipping schreef op 9/16/2014 8:13 PM:
> The quality would decrease if XBoard is scaling it down by a factor that
> is not a full divisor of the what I scaled it up by.  Say if I enlarge
> it by factor 3 and XBoard rendeers it at 50%, we get blurry lines
> despite the integer scale factor.  Or we have a mis-understanding here.
>
I think we have, because XBoard currently does never scale textures. But 
cutting a small part out of a blown-up image of course also gives you 
poorer resolution than cutting from the original would, as I already 
mentioned. But the solution I had in mind for that would never do that. 
At startup it would load the original texture bitmap, and always keep 
that. In response to a board sizing (and at startup), it would then 
create a integer-times magnified version of it, that is just larger than 
the board size (if it was larger than 256x256 to start with), and it 
would use that for cutting.
> That could be a way for field-targetting textures but if that's better
> or worse than scaling might depend on the nature of the texture image.
> Say we had something Escher-ish with different values of "darkness" on
> both white and black, scaling would keep the pattern sane, scale-cutting
> would break it.
Well, I guess there is no one recipe that would work for everything, and 
XBoard is not meant to be a general-purpose image viewer. 99% of the 
users would not want to do anything other than use an image of their 
favorite type of wood or marble to cut out as different as possible 
areas to use these as squares, as if they had a board made from these 
materials (if they use textures at all). Xiangqi is really the only 
variant where this is not good enough, (and only if you would want 
oriental representation), because the textures are used there to 
implement the grid. So I adapted the cutting procedure to preserve the 
grid as well as possible. But it gives some grid distortion of the 
actual size is larger than the bitmap, and cuts out the squares in a 
non-contiguous way if the actual board size is smaller. Users for which 
this is not acceptable can simply supply a texture that exactly matches 
their board size, and never change the latter. This already exceeds what 
XBoard is designed for, but it still can be done, with some effort. The 
only imperfection within XBoard's goals is that there is a maximum size 
to the Xiangqi board without supplying your own graphics. (And IMO it is 
already debatable whether this is a serious flaw; XBoard has always had 
a maximum board size.) Supplying a larger bitmap would push up that 
limit, and the scaling + cutting I proposed above would remove any size 
limitation.
> Let's no do guessing here, let the user tell us what it is.  If we do
> apply guessing, let's at least give the user a way to fixing bad
> guessing manually.
He could fix it manually by changing the size of the supplied bitmap, 
when we describe the behavior in the manual.

We do seem to have a different philosophy here: you prefer more options 
to give the user more control, I prefer fewer options to make sure the 
user has less control. Because every control you give them can be 
abused. Making options to force XBoard to do things that it would by 
itself consider wrong or sub-optimal will unavoidably lead to a large 
number of users configuring this option the wrong way, and coming back 
to complain that things do not work well.
> Alright.  So would you in general accept a patch that
>
>    * adds a branch to the draw-blank-field function,
>
>    * uses the current code/math for textures targeting fields
>
>    * adds a new function for textures targeting whole boards
>
>    * adds two switches to set field/board texture mode for each
>      player color
>
> ?
That depends on what that patch would do for these whole boards, in 
particulare the XQ board (which is really the only case I consider of 
any importance), and how that would look for the available textures. It 
is hard for me to imagine anything that would beat the integer blow-up 
on demand + cutting I proposed above, but I am open-minded about that.

I suppose that in stead of "each player color" you actually mean "each 
square color"? Beware that in Xiangqi the square colors might not be 
what you expect (the board is not checkered, and the colors indicate 
areas). So I am not sure if it would make any sense to ever run in modes 
where light squares use a different mapping as dark squares. For 
oriental XQ I even use the same texture bitmap for both.
> What idea is missing?
How to map a whole-board bitmap to the display in a better way than the 
existing routine does. You said you did not like scaling (and I tend to 
agree; this is how we started and it looked truly ugly), and you did not 
like non-contiguous or overlapping cutting because it would wreck 
Escherish boards. That does not seem to leave much...
> If the image is smaller than the requested display, we have to scale
> things up (speaking of full-board textures only here).  What's wrong
> with that?
That is OK, as long as it is by an integer factor. Even with 
anti-aliasing one-pixel-wide horizontal and vertical lines start to look 
very different depending on whether they fall exactly on a pixel or in 
between.

And it is not just needed for full-board textures. If the texture bitmap 
for single tiles is smaller than a square there also is a problem. If 
the aim is to support unlimited board size, this is a worse concern than 
the full-board issue (which is a minority application).

As for a new option to affect whether the full-board algorithm or the 
single-tile algorithm would be used I would prefer a smart option over a 
simple boolean. Like where you could set an integer to specify the 
minimal size the bitmap should have before the full board algorithm 
would be applied. People can then always mimic the boolean by setting 
that size 0 or 1000000, but that doesn't prevent them from setting a 
reasonable size and let XBoard it handle automatically.

Regard,
H.G.