1090 MHz aircraft transmissions are very short in time. Therefore, it is easily possible for a windowed FFT to miss them, because the signal landed in the time range that's attenuated by the window — or, if the waterfall rate (how often it adds a new row of pixels) is slow, simply because that time range wasn't analyzed at all.
(You can look at this as a sort of “aliasing” — not of the original frequencies, but within the time-series data of “signal power at this frequency” that the waterfall displays. Each FFT produces one sample, and if the transmission lands between two samples, it doesn't appear.)
Assuming I'm correct that this is the problem, the reason your two waterfalls look different is that the time-slices of samples they're sending to the FFT operation are aligned differently, so each one misses different signals.
This problem can be solved entirely by performing multiple FFTs with overlapping windows (processing the same samples more than once) and averaging the computed power or displaying all of them in a fast scroll, but I don't believe Gqrx has that feature.
You can minimize how much is missed by going to FFT Settings and setting the Rate control to the fastest available, but this will not catch absolutely everything due to the lack of overlap.
None of this should affect decoding transmissions — if you use the same decoding software then you should get the same results (except in cases where noise in the receivers made a message just barely undecodable in one and OK in the other).
