[Freecol-developers] Updating audio and video players

[w***@genial.ms]

Hi,

I did some research on the possibility of upgrading the audio
and/or video players.

All their websites are strange and miss important things,
for example: http://www.theora.org/cortado/
Cortado seams near dead, we already have 0.6, which is from
2010 and its last release, though there are some more commits
fixing bugs in 2010 and one in 2012:
http://git.xiph.org/?p=cortado.git;a=summary
Not sure if they would be useful (if yes, compiling from git
might be necessary).

I found jogg/jorbis got some newer version 0.0.17 for a long
time: http://www.jcraft.com/jorbis/
The website is strange and only contains a single download,
no older versions or VCS. Inside are only source files for
both jogg and jorbis and a wrong readme stating there were
compiled binaries, which are missing.
Though its newer than the 0.0.7/0.0.15 we have, which were
never updated. I guess they came from someone having it
compiled for his own game there:
https://code.google.com/p/poi1/downloads/list
I found some newer precompiled jar, which got both inside:
http://mvnrepository.com/artifact/org.jcraft/jorbis/0.0.17
I already got it, adapted the build files and tried it out
successfully. If you dont mind using that third party file
again I could push the upgrade, which would also lower our
jar file count by one, as it contains everything from both
related parts in one file.
If you dont like that you could compile it yourself, but
may need to borrow a build.xml from debian SVN:
https://packages.qa.debian.org/libj/libjorbis-java.html
It would be useful to upgrade, as the changelog mentions
some performance upgrades.
What do you think?


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Thu, 6 Aug 2015 16:22:07 +0200
***@genial.ms wrote:
> I did some research on the possibility of upgrading the audio
> and/or video players.
>
> All their websites are strange and miss important things,
> for example: http://www.theora.org/cortado/
> Cortado seams near dead, we already have 0.6, which is from
> 2010 and its last release, though there are some more commits
> fixing bugs in 2010 and one in 2012:
> http://git.xiph.org/?p=cortado.git;a=summary
> Not sure if they would be useful (if yes, compiling from git
> might be necessary).

That is pretty much the situation when I last looked at cortado.
Not ideal, but it is not getting worse. What we really need from
cortado is a reliable way to tell when the video finishes playing.

> I found jogg/jorbis got some newer version 0.0.17 for a long
> time: http://www.jcraft.com/jorbis/

Good.

> It would be useful to upgrade, as the changelog mentions
> some performance upgrades.

Its probably worth doing. Fedora has 0.0.17 so it is probably OK,
although I agree the website is odd. Let me add that to the growing list
of things I am play testing ATM just to be sure.

Speaking of which, I have played for a fair bit now with the old fonts
re-enabled. I do not yet have a strong opinion about use of Imperator,
but I am firmly convinced that using Liberation is not an improvement ---
I find it much harder to read than our current default. Therefore, unless
we get a lot of 0.11.5 users complaining about the new fonts, I think we
should just drop it.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Sonntag, 09. August 2015 um 03:35 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> Betreff: Re: [Freecol-developers] Updating audio and video players
>
> That is pretty much the situation when I last looked at cortado.
> Not ideal, but it is not getting worse. What we really need from
> cortado is a reliable way to tell when the video finishes playing.

That is pretty much the reason I was looking for an upgrade (and its
subpar performance, especially on first time starting the game after
rebooting, which causes the hacky independent timer to start too early
and not show the end of the video).
Also weird is that for a split second there is a black panel shown in
top left corner for a split second and then moved to the center before
the video starts (but that may possibly be improved in FreeCol code).

> > I found jogg/jorbis got some newer version 0.0.17 for a long
> > time: http://www.jcraft.com/jorbis/
>
> Good.
>
> > It would be useful to upgrade, as the changelog mentions
> > some performance upgrades.
>
> Its probably worth doing. Fedora has 0.0.17 so it is probably OK,
> although I agree the website is odd. Let me add that to the growing list
> of things I am play testing ATM just to be sure.

I think most Linux distros will provide their own jar libraries, I saw
debian using 0.0.17 for a long time, too.
That means the upgrade is more relevant for the people downloading from SF,
which is mostly Windows and maybe Mac users.

I can not discern from your reply if you want to compile it yourself or
use the jar download I mentioned?
I pushed it to my fork now to prevent polluting the official repo with
the jar file. In case you'd like to reuse the build.xml edits it should be
easy to rebase -i and commit --amend.
https://sourceforge.net/u/wintertime/freecol/ci/jorbis17/tree/

> Speaking of which, I have played for a fair bit now with the old fonts
> re-enabled. I do not yet have a strong opinion about use of Imperator,
> but I am firmly convinced that using Liberation is not an improvement ---
> I find it much harder to read than our current default. Therefore, unless
> we get a lot of 0.11.5 users complaining about the new fonts, I think we
> should just drop it.

I also like them less than the local fonts (whichever randomly got choosen).
If we want private fonts we may want to replace them.
Though, I would still say providing private fonts, if they look nice and
contain the complete glyph set for all localizations, is better.
It guarantees all glyphs are there for all people, look the same, are the
same size and there'd need to be less testing for all layout changes.


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Sun, 9 Aug 2015 10:25:34 +0200
***@genial.ms wrote:
>>[Cortado has problems]
> That is pretty much the reason I was looking for an upgrade (and its
> subpar performance, especially on first time starting the game after
> rebooting, which causes the hacky independent timer to start too early
> and not show the end of the video).

I can not pretend to be able to comment much on it having disabled it
ages ago. It takes too long when I just want to run a quick test for
some change. If you can find a better method, feel free to put replace
cortado. AFAICT we only use it because way back then, it was all there
was.

> Also weird is that for a split second there is a black panel shown in
> top left corner for a split second and then moved to the center before
> the video starts (but that may possibly be improved in FreeCol code).

I see it in the bottom right corner, and it is there for quite a while.
Because I have the video disabled, I think that is the splash screen.

> I think most Linux distros will provide their own jar libraries...

Generally correct. It is probably still relevant on linux for the java
installer or builds from source, and minor distros that do minimal package
work. I can confirm that the RedHat world is very against bundled
libraries, and I can see their 0.11.3 package references the system
jogg/jorbis. I never run their FreeCol package though, so I still need to
test.

> I can not discern from your reply if you want to compile it yourself or
> use the jar download I mentioned?

I was just going to grab the jars on my machine, and perhaps compare them
with what debian distributes for consistency.

>>[fonts]
> I also like them less than the local fonts (whichever randomly got
> choosen). If we want private fonts we may want to replace them.
> Though, I would still say providing private fonts, if they look nice and
> contain the complete glyph set for all localizations, is better.
> It guarantees all glyphs are there for all people, look the same, are the
> same size and there'd need to be less testing for all layout changes.

I certainly think we should keep ShadowedBlack. It evokes the game period.
If people want to name their colonies with non-Western scripts, and then
find they do not display nicely with ShadowedBlack, I think we can just
say "dont do that". However that is a special font used for visual
effect. Liberation is just a (nice I admit) general text font, which
does not provide any special visual impact, at the cost of us (in theory)
having to keep it updated.

So how does Java choose its fonts? I can not see any fonts in the openjdk
packages (or their requirements lists) on my machine, so I am betting for
linux at least it is just wrapping up what the windowing system is
offering. If so, that is great, because the windowing system will be
offering what was chosen by the last person to run the font selection
tool, which would be me, which explains why I like the default java font
here:-). Do we know what happens on windows? I do not see fonts in the
Mac java bundle either. IMHO if you are worried about user's not seeing
certain glyphs, the best thing we can do is get out of the way and let the
user choose a font that has good glyph coverage *in the area they care
about*, and try to be conservative about what we emit[Postel]. If I am
right about what Java is doing, then we are doing the Right Thing in
0.11.5.

Providing a private font so as to force a uniform appearance and thus cut
down on testing is misguided IMHO. I do not like forcing aesthetic
choices on users, and unless we hard code the font names and pull fonts
specification out of resources.properties we are admitting that users are
allowed to change the fonts. I certainly do not want to stop people with
bad eyesight increasing the font size for the general text for example...
that will probably be me in a few years. However I do *not* think we
are obliged to test for all sorts of weird fonts a user might specify.
IMHO if the layout is good with whatever Java thinks Serif-PLAIN-12 is,
then that is enough. What we *do* need is a bit more elbow room in tight
panels like InfoPanel so that minor differences in glyph size and
spacing do not indeed matter. Which is why we need BR#2888.

I mentioned "user complaint" though as a driver here. With 0.11.5 out for
not-even-a-week we can defer making decisions here and wait for comment.
My guess is we will get nothing unfavourable unless we ask:-).

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Sonntag, 09. August 2015 um 12:54 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> Betreff: Re: [Freecol-developers] Updating audio and video players
>
> On Sun, 9 Aug 2015 10:25:34 +0200
> ***@genial.ms wrote:
> >>[Cortado has problems]
> > Also weird is that for a split second there is a black panel shown in
> > top left corner for a split second and then moved to the center before
> > the video starts (but that may possibly be improved in FreeCol code).
>
> I see it in the bottom right corner, and it is there for quite a while.
> Because I have the video disabled, I think that is the splash screen.

No, the splash window is already destroyed and the main window displaying
the canvas background before that happens for me, so I would exclude
this possibility.
I think, I'll look at how the video panel is created and if its moved
when already visible.

> I was just going to grab the jars on my machine, and perhaps compare them
> with what debian distributes for consistency.

They have a single jar containing both parts of the library, like the one
I found.

> >>[fonts]
> I certainly think we should keep ShadowedBlack. It evokes the game period.
> If people want to name their colonies with non-Western scripts, and then
> find they do not display nicely with ShadowedBlack, I think we can just
> say "dont do that". However that is a special font used for visual
> effect.

We might want to check for a more complete version of that font.
I would also like to get this automatized some more. It looks bad if there
are those rectangle glyphs.
As the header font is only sparsely used, we could check each string using:
if(font.canDisplayUpTo(string) != -1) font=normalfont;
That could even allow us to get rid of the font override .properties files,
but would slightly complicate display code.
Alternatively we could change the command line option to switch normal and
header font or even all 3 or add more than one option, but thats tedious
for the users.
Or we could add a simple mod, which just sets the header font to the
same font as the normal font, by overriding the resource key.

> Liberation is just a (nice I admit) general text font, which
> does not provide any special visual impact, at the cost of us (in theory)
> having to keep it updated.

To me it just looked like it had weird hooks attached to the glyphs. :p

> So how does Java choose its fonts?

My understanding is it first checks the fonts provided by the OS for some
font similar to what was requested (serif/sansserif/whatever) and then
falls back to private fonts placed in $JAVA_HOME/lib/fonts .
I see there are 8 Lucida*.ttf files, in an incomplete set of
Bright/Sans/Typewriter and regular/(demi)italic/(demi)bold combinations.

> IMHO if you are worried about user's not seeing
> certain glyphs, the best thing we can do is get out of the way and let the
> user choose a font that has good glyph coverage *in the area they care
> about*, and try to be conservative about what we emit[Postel]. If I am
> right about what Java is doing, then we are doing the Right Thing in
> 0.11.5.

Well, I think checking if the font provides all glyphs in each string to
be displayed next, is the way to go then.

> I certainly do not want to stop people with
> bad eyesight increasing the font size for the general text for example...

All fonts can be resized and we enforce size, so that is a different problem,
which was recently fixed through the --gui-scale option. :)

> I mentioned "user complaint" though as a driver here. With 0.11.5 out for
> not-even-a-week we can defer making decisions here and wait for comment.
> My guess is we will get nothing unfavourable unless we ask:-).

Oh well, if we wait for people to be bothered enough to complain about any
minor glitch, we could wait for a long time. Just compare the downloads to
the number of people writing BRs. ;)


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Sun, 9 Aug 2015 15:17:31 +0200
***@genial.ms wrote:
>>[Debian]
> They have a single jar containing both parts of the library, like the one
> I found.

Not AFAICT. https://packages.debian.org/jessie/all/libjorbis-java/filelist
shows their package contains separate jogg.jar and jorbis.jar. Sid is
similar. Not that packing it together buys us that much.

>>[fonts]
> As the header font is only sparsely used, we could check each string using:
> if(font.canDisplayUpTo(string) != -1) font=normalfont;

OK, please do that. That takes out the guesswork.

> > So how does Java choose its fonts?
>
> My understanding is it first checks the fonts provided by the OS for some
> font similar to what was requested (serif/sansserif/whatever) and then
> falls back to private fonts placed in $JAVA_HOME/lib/fonts .
> I see there are 8 Lucida*.ttf files, in an incomplete set of
> Bright/Sans/Typewriter and regular/(demi)italic/(demi)bold combinations.

Not seeing that here. I suspect that is a packaging decision. When I
wrote a trivial program to list the fonts available to Java, I got a list
of the same order as the output of xlsfonts(1), so I think there has been
some effort by RedHat to make installed fonts visible.

Cheers,
Mike Pope

[Michael T. Pope]

On Mon, 10 Aug 2015 21:21:25 +0930
"Michael T. Pope" <***@computer.org> wrote:
>[fonts]

Further to the fonts discussion, I have now done a bit more play testing
with just Imperator restored. My conclusion is that it is also less
readable, and not sufficiently interesting or distinctive to persist with.
Does anyone really want it?

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Mittwoch, 12. August 2015 um 13:01 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] Updating audio and video players
>
> >[fonts]
>
> Further to the fonts discussion, I have now done a bit more play testing
> with just Imperator restored. My conclusion is that it is also less
> readable, and not sufficiently interesting or distinctive to persist with.
> Does anyone really want it?

I'd say removing them from the base resources should be done.
We could move them into a trivial new mod, which just overwrites the 2
resource keys and contains the fonts. I'm not sure if thats useful.

The code I wanted to add for checking if strings are compatible with
the font will take a bit longer. I could easily hack it in on all
call sites, but I don't like that solution, as it would often need
to extract the string from a JLabel, which was just created inside
Utility together with the Message call to translate it.
These Utility methods look trivial, almost tempting to get inlined,
because there is a huge amount of overloads already and I might need
to triple that amount.
I'm thinking of adding some more methods to FontLibrary first, which
take the string and use the font type parameter only as a hint to
find the best match upon the 3+1+1 choices.

While looking at Utility I felt I had found some inconsistency with
the Message handling.
Sometimes there is a direct call to Messages.message(stringkey)
and other times Messages.message(StringTemplate.key(stringkey)).
They seem equivalent to me, but the first trims the string, the
second does not. Do you know why? Could that trim call be removed?


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Wed, 12 Aug 2015 19:24:38 +0200
***@genial.ms wrote:
> I'd say removing them from the base resources should be done.
> We could move them into a trivial new mod, which just overwrites the 2
> resource keys and contains the fonts. I'm not sure if thats useful.

The win I would like to see is for us to just not package them any more.

> The code I wanted to add for checking if strings are compatible with
> the font will take a bit longer. I could easily hack it in on all
> call sites, but I don't like that solution, as it would often need
> to extract the string from a JLabel, which was just created inside
> Utility together with the Message call to translate it.
> These Utility methods look trivial, almost tempting to get inlined,
> because there is a huge amount of overloads already and I might need
> to triple that amount.

Sometimes there is no better solution than a lot of overloading. The
alternative is imposing a lot of discipline on the call sites. Up to you.

> While looking at Utility I felt I had found some inconsistency with
> the Message handling.
> Sometimes there is a direct call to Messages.message(stringkey)
> and other times Messages.message(StringTemplate.key(stringkey)).
> They seem equivalent to me, but the first trims the string, the
> second does not. Do you know why? Could that trim call be removed?

My guess is this is just a historical accident. StringTemplate is still
relatively new. All i18n used to go through the first call, and yes, that
was often really awkward. There are a lot of places where we really want
to pass a StringTemplate, but some callers just have a simple key, so
there has to be some way to bridge the gap. As to the trimming... I had
not idea it did that. Would you like to try removing it and see what
breaks?

Quick warning that next week or so is looking extra busy for me, and I
have almost cleared the patch queue of stuff that has had sufficient
testing, so do not be surprised if I go quiet for a bit.

Cheers,
Mike Pope