Isn't it because of what you mention in comment #8 of bug #395738? EOG uses incremental image loading...

Yes it is. EOG should have some fallback code though.

I tend to say that this is sometheing GdkPixbufLoader should do for me transparently.
Theoretically I shouldn't have to implement workarounds for a specific loaders problems, which would remove quite some usefulness from GdkPixbufLoader in my eyes. 

(In reply to comment #3)
> I tend to say that this is sometheing GdkPixbufLoader should do for me
> transparently.
> Theoretically I shouldn't have to implement workarounds for a specific loaders
> problems, which would remove quite some usefulness from GdkPixbufLoader in my
> eyes. 

No, EOG simply doesn't support non-incremental loading. It's far from a work-around to support it, and it could hit any loader (a few loaders go out of their way to mimic incremental loading, which is not where the work should be done).

(In reply to comment #4)
> No, EOG simply doesn't support non-incremental loading. It's far from a
> work-around to support it, and it could hit any loader (a few loaders go out of
> their way to mimic incremental loading, which is not where the work should be
> done).
> 

But that would mean that every GdkPuxbufLoader-using application would have to implement the GdkPixbuf-fallback (that might be the better word here than "workaround) to be really on the save side, as theoretically every loader could be non-incremental (even it is now; you might never know).
This doesn't make it appealing to use GdkPixbufLoader as you still need to implement the fallback. You could as well just use the fallback alone without fiddling with GdkPixbufLoader.

Additionally I shouldn't have to know about the loaders, that's what GdkPixbuf and GdkPixbufLoader are there for.

But maybe I just want to use GdkPixbufLoader for things it wasn't designed for.

5 years later, any news on this?

This seems to have been fixed in gdk-pixbuf in the meantime by bug 629474.