Re: XBoard 4.7.3: Full board textures + maximize window

Sebastian Pipping schreef op 9/17/2014 5:55 PM:
> Hello,
>
>
> On 17.09.2014 10:02, H.G. Muller wrote:
>> The problem seems to be that you want
>> one and the same texture bitmap to work over a very wide range of board
>> sizes.
> well, yes, of course.
XBoard was just never designed to do that. Before we switched to Cairo 
plotting, every single board size needed a separate set of images for 
the pieces.
> Say hello to non-integer factor image scaling, please.
I tried that, and it looked very ugly on the textures, and in particular 
on the Xiangqi board.
> With the shipped xqboard.png, it looks better now, but that does have to
> do with the specific image.  In particular:
>
>   * It can be crashed by resizing (small, big, crash), e.g. by running
>
>       # wmctrl -r "xboard:" -e 0,0,0,100,100
>       # wmctrl -r "xboard:" -e 0,0,0,1000,1000
>
>     which makes XBoard crash with a Cairo assertion
>
>       xboard: [..]/cairo-surface.c:930: cairo_surface_destroy:
>       Assertion `((*&(&surface->ref_count)->ref_count) > 0)' failed.
>
>     (Running cairo 1.12.16 over here).
Hmm, that is bad. I added two surface destoys, one for the original 
board, the other for the scaled one. The latter is only made and 
destroyed when the static variable n != 1., the former is always 
destoyed and recreated. I would have expected that to be OK. It is hard 
to debug if I cannot trigger the scaling. Perhaps I can with a strongly 
demagnified bitmap, which already needs scaling when I do a full screen 
on my display.
>   * The lines
>
>       if(w > 256 & h > 256) { // full-board image?
>         while(squareSize*9 > n*w || squareSize*10 > n*h) n++;
>       } else {
>         while(squareSize > n*w || squareSize > n*h) n++;
>       }
>
>     are the exact guessing that I asked /not/ to do.
Yes, I already warned that I had not addressed that point yet. There 
seemed little point in doing that if we could not get the scaling 
working, or when the results would be unsatisfactory.
   The problem is that the way you want it to work would wreck the 
behavior I would like to have for the version we distribute. The Xiangqi 
board that goes with the distro (preferably the ones we already have) 
should at least display at any standard board size, which means upto 129 
x 129, and in the old code that was not the case, as your initial 
screenshot showed. So I need a type of scaling like I tried to implement 
with this patch, wich would occur without having to set an option that 
would wreck the non-full-board textures by also forcing the scaling on 
the latter by starting to scale those to full board size. That would 
sacrifice resolution way too early; it gives much better results to have 
overlapping high-resolution tiles than disjoint low-resolution tiles. 
The similarity of the tiles can be further disguised by randomizing 
their orientation (although I am not sure XBoard does that. WinBoard 
doesn, though).
   You convinced me that there would be some merit in an option that 
forces contiguous cutting, achieved by scaling the texture to exactly 
the required size, for Escherian boards.
>     Furthermore, "&" probably should be "&&" and those
>     loops could be resolved by using a non-loop formula.
>
>   * It's still as broken for other_1800x2000.png .
>
>
> To get it compiling, I needed to apply the gettext 0.18 patch from
> https://savannah.gnu.org/bugs/index.php?39970 . It would be cool to have
> that applied upstream: even Debian stable has gettext 0.18 by now.
> Which distro and version of gettext are you running?
I am running Ubuntu 10.04, which has gettext 0.17 and does not support 
higher versions.
I don't really know much about Linux, and Arun Persaud does the gettext 
and autotools stuff, but this gettext problem seems very tough. The 
Debian patch would prevent me to compile it. It seems inconceivable that 
it would not be possible to have a version that would work on any 
gettext version from version 0.01 and up, as we only use the most basic 
features (the _(), N_() macros, and I think one other). This is 
confirmed by the fact that we never have to change anything in the 
actual C source. It is purely an autoconf problem, which drags a number 
of m4 macros from somewhere, which then aren't the version that some 
automatically generated Makefile then thinks it must insist on.
> You can use wmctrl to blow up the window size even beyond screen size, e.g.
>
>    wmctrl -r "xboard:" -e 0,0,0,2000,2000 ; echo $?
>
> With wmctrl 1.07 and XFCE that works as expected over here.
OK thanks. That would be very useful.

Regards,
H.G.