Gosu load images in separate thread

By bbb Date 2015-08-22 14:55

I have coded a simple CBR reader in gosu for gigs, and it have served me surprisingly well, so I decided to polish it up, refactor and release into open source. There is however single issue that I'm having hard time dealing with: when gosu reads big image file from hdd - like, when turning a page, because I don't won't images read all at once - it (quite expectantly) freezes application for a bit. To solve this, I tried to cache images in separate tread, like so:

    Thread.new {
      @cache[img] = Gosu::Image.new(img, tileable: true)
    }

and than access it this way:

   def access img
     @cache[img] ||= Gosu::Image.new(img, tileable: true)
   end

However, images loaded in separate thread appear blank-white. This also happens if I wait until file is completely loaded before accessing it (using mutexes or simply waiting before turning the page). Is there any way to load images in separate thread in gosu?

By jlnr (dev) Date 2015-08-22 16:37

Yes and no. A client once ran into the same issue, and for a while there was an experimental Image.async_new method that returned a 'placeholder' object. You could ask this object whether it was ready? and then call get to extract the Image on the main thread. (I'm not sure if it is a Future or a Promise in computer science terms…I always get them wrong.)

The problem with the async_new interface was that I'd also have to add Image.async_from_text, Image.async_load_tiles, Sample.async_new etc. to be consistent. My client ended up not using it anyway, so I've silently removed async_new.

It would be pretty easy to just make most of Gosu's resource management thread-safe. Alas that wouldn't help, because Ruby is still not executing code from C extensions on separate threads (unless I've missed something in the changelog).

Anyway, that sounds like a cool project, and I'll see if I can bring Image.async_new back as an experimental feature. I miss it as well. I've opened an issue on GitHub that you can subscribe to: https://github.com/gosu/gosu/issues/294

By bbb Date 2015-08-22 16:53

Wow, thanks for such quick response :D

By bbb Date 2015-09-17 14:57

For a game, loading your assets in separate thread might not be a solution at all, because performance matters, and Ruby Threads are not very fast. I'd advice you to consider other ways to solve this issue first.

By Salazar Date 2015-09-18 06:27

For a complete game, maybe, loading tilesheets and simple images in png/jpg is the best way, I think. But I construct many of my graphics "on the fly", using RMagick...((( And beside this, I have a VERY complex GameObjects)) For example, I need to draw a highlight shape of my sword or armor, when mouse enter an image. And for now I dont't know other way of doing this, rather than to create a shape-image for every object in initialize method(( My "Create Hero" screen consisits of more than 50 objects, such as push-buttons, text images, background, scrolling windows and so on)) To load this stage (and only this!) I need about 20 seconds. But the next screen is "Choose profession" screen, and next is "Inventory screen" and "Battle field" and more, and more)) I dont; think, that anyone wants to wait about 20 secs for each screen loading)) Today is not the '90th)))

By bbb Date 2015-09-18 07:51

Do you really need to generate all the graphics on the fly? Wouldn't it be possible to just use RMagick to generate them, save, and treat just like other assets? Now, I don't want to criticize your approach, as you might know your needs the best, but I'd expect ImageMagick running in background Thread to cause noticeable FPS drop on many machines.

By jlnr (dev) Date 2015-09-20 13:38

I'd suggest lazily generating these images during development, and then at some point you write them all out to PNG files. That way your players don't need to have ImageMagick installed on their machines.

By Salazar Date 2015-09-20 14:31

Yeah, something like that))