Feature: Thread sf::Image loading

[h0tw1r3]

There's really no way to speed it up (storage is only so fast), and on lower end machines it's probably the most noticeable slowdown in the program.

Thoughts?

head of gprof barf:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 33.96      0.36     0.36                             stbi__parse_zlib(stbi__zbuf*, int)
 30.19      0.68     0.32                             stbi__resample_row_h_2(unsigned char*, unsigned char*, unsigned char*, int, int)
  5.66      0.74     0.06                             decode_cabac_residual_nondc_internal
  2.83      0.77     0.03                             _mcount_private
  1.89      0.79     0.02                             SQVM::Get(SQObjectPtr const&, SQObjectPtr const&, SQObjectPtr&, bool, int)
  0.94      0.80     0.01    20469     0.49     0.49  FeSettings::do_text_substitutions_absolute(std::string&, int, int)
  0.94      0.81     0.01     9249     1.08     1.08  FeTextPrimative::setString(std::string const&)
  0.94      0.82     0.01     7864     1.27     1.27  FeTextPrimative::draw(sf::RenderTarget&, sf::RenderStates) const
  0.94      0.83     0.01      408    24.51    24.51  FeListBox::init_dimensions()
  0.94      0.84     0.01      407    24.57    81.27  FeListBox::on_new_list(FeSettings*)

[mickelson]

My thought is that if we stuck with stb_image, Attract-Mode could do the image loading step itself, but at first just load the image dimensions (using stbi_info()) and otherwise set the image to blank. The image data could be loaded by a background thread.... it seems to me this sort of approach might reduce the noticable slowdown when loading images...

I think getting the image dimensions is necessary at this point, attract-mode assumes it has them on after calling to load the image.

[h0tw1r3]

I think getting the image dimensions is necessary at this point, attract-mode assumes it has them on after calling to load the image.

Why does AM care about the size when loading a piece of media? I thought that the layout determined the displayed size, which is usually different than the actual media dimensions.

[mickelson]

Why does AM care about the size when loading a piece of media? I thought that the layout determined the displayed size, which is usually different than the actual media dimensions.

Two reasons:

1. Each image/artwork has an SFML Sprite associated with it, which is what is used to actually display the image. sf::Sprites have a position and a scale (but no "size"). We're given the position by the layout, but to calculate the scale the frontend needs to know the "size" specified by the layout and the actual size of the image texture. One way to work around this would be to defer setting the image's scale until after we have completed the (delayed) loading of the file.
2. There is a "texture_width" and "texture_height" property available to layouts and modules, and the documentation says those values will be available during the various tick/transition/signal callbacks. So not having these values available will change the documented scripting behaviour, and will probably mess up somebody's animation effects if the behaviour gets changed.

[mickelson]

Related to Issue #96

[mickelson]

See also #342