@jbacker, but dependency graph would like to stay away from such ill-formed queries:

• Visibility might be driven, so if anything, such query can only run after the entire graph evaluation.
• Visibility depends on your interaction intent: object might be visible for the viewport drawing, but might be invisible for the selection buffer drawing pass.
• Visibility depends on whether you are interested in objects coming from duplication system.
• Visibility depends on duplicator settings.

While things above are technically known by dependency graph, there are various things which dependency graph does not (and should not) be worried about:

• Visibility depends on viewport settings.
• Visibility depends on render engine.

I can not think of a clear API which will be generic enough to be justified to be done as a core part of dependency graph, which will also be giving reliable results without slowing down evaluation for every other case.

Can only think of some utility function in dependency graph query API which will facilitate your goal but will still require having you doing some preliminary check:

• You check for obvious early outputs, like viewport and render engine settings
• Dependency graph cans store a map of ID types which are in the graph (simple array, indexed by an an ID type). This is super easy to control.
• Introduce some function in query API which will return whether ID of a given type is reachable via DEG_OBJECT_ITER_BEGIN with a given flags.
• This function can do early output check if the ID is not in the graph at all.
• Otherwise, it's doomed to do the DEG_OBJECT_ITER_BEGIN() with the given flag and do pretty much what you're doing here.

@Jeroen Bakker (jbakker) I have tested and your solution works, but I'm not sure if this is the way to fix or not... The decission is for @Clément Foucault (fclem) and @Brecht Van Lommel (brecht)