Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window

[Sebastian Pipping]

Hi!


On 18.09.2014 11:28, address@hidden wrote:
>> I'm pretty sure it depends on the kind of texture.  And with SVG,
>> scaling should look sharp at any resolution anyway.
> 
> Well, it applied to the texture that I considered looking best as new
> default theme for XBoard (the beechwood / cherry theme). SVG only looks
> sharp on images that lack detail below a cerain size, because they consist
> of evenly colored fields with sharp boundaries between them. At large size
> such images would look like drawings, because they lack detail that the
> eye expects of natural substances. And if you make it so detailed that
> even at the largest size there are details comparable to the pixel size,
> it would start to average over those as smaller sizes, producing a hazy
> look that eventually will degenerate into an evenly colored mist.
> 
> Anti-alisaing is another problem; unless you really have a display where
> the pixel size is much smaller than the resolution of the eye, a
> 1-pixel-wide black vertical or horizontal line, drawn just between two
> pixels, will be a two-pixel-wide gray line. At square sizes of 50x50 that
> will be very noticeable.

If I answer that in details, we drift to a bitmap versus vector
discussion.  So I'll focus on one point: I recently had a case where a
one-pixel line in vecotr dd not end up as that when rendering.  The
solution was to move it up/left/.. by 0.5 in my case.  In short: The
specific SVG image was at fault, not the rendering.  It should be the
same with XBoard: Whatever looks broken needs to be the textures fault,
not XBoard's.


>>> 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.
>>
>> How so?
>>
> If an option would force texture bitmaps to be scaled either to board size
> or square size, we would have to set it for square size to prevent that
> the 129x129 textures we supply with XBoard for tiling, and then it would
> not size up the supplied XQ board at the larger board size, (as it is
> already larger than a square) and give exactly the artifact you showed in
> the image attached to your first mail.

If the default is

 * single-field texture mode and

 * single-field western chess board texture

that would work well in my eyes.  If the user now wants a full board
texture, he/she would adjust

 * texture type and

 * texture image path

both.  That would keep western chess defaults sane and still support
Xiangqi in full board mode, well.

I really don't see how that would be wrecking any default shipping for
anyone.


>> I don't think that's the case if you separate single-field and
>> full-board modes properly.  I still hope for that to come.
>>
> Full-board modes are problematic anyway, because full-board bitmaps have
> to be specific for one board format. No matter whether you scale or cut,
> the XQ bitmap will never be usable with Chess or Go, even if you would
> want to play that on grid points, because it is 9x10, and when you cut it
> up 8x8 or 13x13 it gets totally out of register. The same would hold for
> Escherian 8x8 boards when you switch to 10x8 Capablanca Chess or 10x10
> Draughts. You just cannot expect such things to work globally. XBoard
> allows you to use them, but necessarily this will result in the loss of
> some functionality that would exist when you were simply tiling squares.

Right, but I don't see why anyone would expect that from a full board
texture.


> Note that for tiling an alternative for scaling up textures that are
> smaller than teh square size would be to tile the textures to a larger
> bitmap before cutting from them, so that there already is some repetition
> (and possibly discontinuity, if the original texture image did not have
> periodic boundary conditions) within a single square. With the texture we
> have, this might look better. In fact this is how I made the xqwood.png
> image; that image is 441x490, and the original wood bitmap I had was only
> 256x256. So I tiled it first, before drawing the XQ grid on top of it.

I know and I agree that approach can be a good choice for some textures.
 This is my understanding of different texture types and what you could
sanely do with them:

  Single tile
    Wood/marble
      random rotation, flipping, enlarge-and-cut, float scaling fine
    Escher'ian
      float scaling fine
  Full board
    float scaling fine


> I must admit that the new handling of themes introduced with v4.8 will
> reduce the problem with options that interfere with the standard theme, as
> we can only include them the theme definition of one specific theme. But
> it is still important to keep the length of theme definitions manageable.

Where can I read more about how themes work?


>> but I consider the fact it doesn't work
>> for other full board images rather sad.  I don't really see why XBoard
>> graphics quality should /not/ be as high as that of
>>
>> http://blog.hartwork.org/__images/setup_imitate_playok.svg
>>
>>
>> viewed in Firefox at any given zoom factor.  Maybe that's a goal for
>> XBoard in 2015.
>>
> 
> That image has no texture, and quite frankly, I think XBoard with the
> xqwood.png texture looks much better at all sizes below 72x72.

That SVG is not optimized for small sizes.  It was more about giving an
example.  For larger sizes, it looks way sharper than XBoard though.


> I also
> don't see that this derives any advantage from using SVG.

Sharper lines, for instance.


> XBoard's pieces
> are already SVG, and I think the board image used would scale just as well
> as PNG as it does as SVG.

Ccaling PNG will get blurry or pixelated at some point, to an extend
that the user does notice.


> There is one board size where the grid lines are
> exactly one pixel wide, and at this board size a pixelated version of the
> image perfectly represents it. A sized version of that image, to which you
> apply anti-aliasing should be exactly the same as an SVG rendering with
> anti-aliasing of it.

I'm not sure about that.  Anti-aliasing needs to guess what is a line,
SVG knows what is a line.


> For Escherian boards the cutting would not work, and exact (non-integer)
> scaling would be needed. But scaling to the actual board size would fail
> for variants that require different board formats.

I think that's mixing too manay cases into one pot here.

> 
> Perhaps there should be an option like -textureBoard "10x8", which could
> tell XBoard that the texture image is a full-board image of a 10x8 board.
> So that XBoard could cut an 8x8 part of it (and scale it exactly to the
> actual board size) when you play normal Chess. The value "0x0" (the
> default value) could be used to indicate it is just a texture with no
> intended relation to the square or board size, while "1x1" would indicate
> it should be scaled exactly to the square size. The bitmaps would be
> extended by tiling if they are not large enough for making the original
> cut (e.g. if you play Shogi with only an 8x8 texture board available),
> before it is scaled to fit. That means a bitmap specified as "1x1" would
> be tiled on every square as an exact fit.
> 
> What do you think of that?

You seem to strive for a generic approach, which is cool, but it's not
the right way/place to generalize.  Show me a 10x8 full board image that
is not made of the same texture for white and black squares where
re-using parts for a 8x8 board looks meaningful.  I consider that rather
unliky.


> I still badly regret I upgraded from 8.04 to 10.04. My sound card started
> stuttering, the WiFi hardware of my computer was no longer supported, and
> I cannot use USB at all. I tried to install 12.04 on a virtual machine,
> and the install made the VM crash. From what I have seen from other
> people, 12.04 has a completely new user interface that is complete crap. I
> would never want that on any computer I actually had to work on. So if
> 10.04 gets unworkable, I guess I would have to switch to another distro
> (people recommend Fedora).

To make it short:

 * I totally get why sound and wifi problems are frustrating and made
   you regret trying a new version.  I've had some experiences along the
   same lines.

 * Most distros offer several desktop environments.  No matter what the
   default in recent Ubuntu is, you could use it with XFCE, Awesome,
   you name it.  Just KDE 3.x and GNOME 2.x might get difficult.

If you want help with finding something that looks and works like you
want to, I'm happy to help in a distro-neutral way off-list.  Just get
something with security updates, please.


> That I switch to gettext 0.18 or 0.19 would not help other users that have
> gettext 0.17 or 0.11 on their system (and might have a good reason for
> wanting that).

I get the point, but you might well be the only desktop user still
running gettext older than 0.18 in a few thousand users.  And for
something as old as a few years, it's okay to tell users to update to be
able to run your software, really.

Best,



Sebastian