On the web it's almost always better to have a single click event listener at the top of a hierarchy. For example in a tabular data representation the <table> element would listen for all its child elements instead of each <tr> or <td> having their own listeners, since the event knows its originating element anyway.

Instinctively I'd do the same in LibGDX Scene2D and put my ClickListener to the Stage instead of the Actors or Groups.

So far I haven't seen anything which suggests I'm doing it wrong, but as I'm new to LibGDX I thought I'd ask.


I'm a bit worried about possible memory management issues, similarly to when certain Disposables aren't properly disposed, or when I forget to use pooling on objects which are constantly reused.


In short answer, Stage extends InputAdapter so you could subclass Stage and override all of the InputAdapter methods. If you did this, you would have to implement your own algorithm to determine which Actor was touched.

Personally, I think that using the event propagation and hit detection that Stage already has is worth putting the listeners on the Groups/Actors. However, this doesn't mean that you have to handle all events in the Actors themselves.

If you want all input handling to be done in a central location, I suggest using the command pattern. This way, you can inject commands into your Actors that they will call when they receive input and the commands will forward any relevant data to your central input handler.

Answer After Clarification

As far as memory overhead, your memory footprint won't be drastically different by attaching listeners to your Actors. Regardless of whether you use attach any listeners, each Actor creates a DelayedRemovalArray to hold all of the listeners. Each of your listeners will take differing amounts of memory, depending on how much your data listener implementation stores, but this amount will probably never be large.

Listeners attached to Actors are not pooled and, unless you use a resource needing disposal in your handler, do not need to be disposed. The garbage collector will take care of all listener handles when there are no more references to them.

The only processing bottleneck I can see with listeners would be if you are constantly creating them and destroying them. You could potentially pool listeners, but then you would have to free them once the Actor using them is no longer in use. In this scenario, I suggest pooling the Actor instead as similar Actors are going to need similar listeners.

Trying to optimize listener memory is probably an over-design to begin with and I would wait until they have become a proven problem before doing anything about them. Having Actors hold their own listeners will make your game more modular and will prevent a monolithic event handler which will be hard to maintain.


The benefits of keeping the code modular and using the Stage's event propagation system outweigh any potential memory optimization by having a single monolithic listener. I suggest putting them on the Actors.

  • \$\begingroup\$ I'm sorry, I have added a clarification that I'm expecting a single click event on one of the Actors, so I shouldn't have mentioned the more generic InputListener at all. However, mentioning the command pattern is a great idea, I've recently read more about this in the "Game Programming Patterns" book. \$\endgroup\$ Aug 18 '16 at 21:39
  • \$\begingroup\$ Could you clarify your question some more? I'm not quite sure what you're asking. \$\endgroup\$ Aug 19 '16 at 16:09
  • \$\begingroup\$ I've added a clarification to the original question. Essentially I'm concerned about memory leaks. \$\endgroup\$ Aug 20 '16 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.