GOOM (and other visualisations) multi-threading?

I was feeling greeen some time ago, and replaced my AMD dual-core HTPC with a nice ION system. This is working nicely I must say, except for one thing: The visualisations (mainly Goom & some ProjectM presets). These are pretty slow and run <25fps.

Now I noticed that when these are running, only one of the cores is stressed and the other one seems to be doing (close to) nothing.
And, I might be wrong here, but I have the idea that the core that is drawing the OSD, is also responsible for the visualisation.
Wouldn't it be usefull to split those tasks over the seperate cores (if available) and possibly even make the visualisations multi-threaded?

Note that I haven't got any decend programming skills, but these are just thoughts. Maybe I am asking something utterly impossible

This would be a request for the corresponding upstream projects, not us. ProjectM is actually multi-threaded, though not like you want it to be, and we have it disabled because their thread code is utter trash. It multi-threads only loading of preset config files in an attempt to smooth transitions.

TBH screensavers aren't really all that well suited for threading since many calculations are dependent on one another. A better solution would be to do the work with a shader on the GPU.

althekiller Wrote:This would be a request for the corresponding upstream projects, not us. ProjectM is actually multi-threaded, though not like you want it to be, and we have it disabled because their thread code is utter trash. It multi-threads only loading of preset config files in an attempt to smooth transitions..

Aha, I understand...
But is it a correct assumption that only one thread is being used for both rendering the XMBC OSD and the visualisations? Isn't that something that the XBMC team can split up?

You can only use opengl from one thread at a time.

bobo1on1 Wrote:You can only use opengl from one thread at a time.

Aha, ok.. That explains a lot
Too bad though. The ION system is quite nice to use for XBMC. It's just not enough to make these visualisations run right on a HD resolution. It would have been nice if this could be solved in an easy manner, but... it seems it's not that easy

Anyway, let's send an email to the GOOM authors

goom has been dead since 2004 i believe

spiff Wrote:goom has been dead since 2004 i believe

So I noticed. Their website is quite out of date. Email function doesn't work and there is a lot of messy stuff in their bugtracker which hasn't been cleaned out in months.
It seems I'm out of luck: I guess there is no chance to get a decent looking visualisation running at full speed on my ION board

[edit]
Indeed: 2005:
http://sourceforge.net/projects/goom/files/goom2k4/

Maybe someone could be interested in continuing the work on this project? One could also update the fact that right now GOOM only uses one channel (Half of GOOM is not responing to the sound/music)

I sent an email to te creator of Goom2k4 and this is what he said:

Quote:I knew Goom is used in XBMC (and quite proud of that).

It would be possible to make it multi-threaded and it shouldn't be that hard because 95% of time is spent into a single method.

I considered doing it a few years ago, so I have the idea somewhere in mind. But at this time, goom was only limited by memory bandwidth, so it would have been useless, however this probably is changed now.

For now I'm very busy, so I can't promise I'll be able to do more than pointing you to the right directions and explain the code.

As I am simply to stupid for this: is there someone who is willing to pick this up? As you can see, the creator is willing to help you out, with pointing you in the right direction and stuff. I can give you his contact details by PM if needed.