Beta version of GLCD library version 3

E.U.A,
I assume you meant the middle 2 entries. (#2 and #3 in this list)

Code Compiled For        | XTAL Speed | GLCDDemo FPS
1)            16Mhz       | 16Mhz       | 15.08
2)            16Mhz       | 20Mhz       | 13.46
3)            20Mhz       | 16Mhz       | 18.56
4)            20Mhz       | 20Mhz       | 16.87

Those do look odd. But it is hard to tell exactly what you have done.

You appear to be intentionally compiling code with the F_CPU set incorrectly, which will generate incorrect delays.
Is that what you did? How exactly did you build the images?

That said, I would have expected to see the FPS results for #2 & #3 to be reversed, assuming there was no change in configuration
and the display is still functioning properly showing
a proper looking FPS display.

Are you sure the FPS values for #2 and #3 are not swapped?

In the case of #2, compiling with F_CPU set to 16mz but running the processor at 20mz
will cause delays to be shorter than #1 and all the rest of the
code should be a little bit faster as well. Even if the h/w polling
erases some of the shortened delays I would not expect #2 to be slower
than #1.

For #2 are you saying you used the exact code image from #1
on the same processor using the exact same glcd (not same model, but the very same one) with the exact same pin configuration (no recompile, no new download?) and the only change between #1 and #2 is simply replacing the crystal with a 20mz?

And for #3, same thing as above, with respect to #4
with no recompile and no new download no changes, simply swapping crystals?

If so, then I agree something odd is happening.

But I have seen some odd things in the past. For example,
sometimes if the timing is just right, running a bit slower can
actually yield faster results. This is because when the timing is
just right, the code will test a hardware flag and not have to
spin on it because it is already ready. In that case you save a
loop iteration and save a few clocks. But normally it is very
rare to see this. And in the case of jumping from 16mz to 20mz
I would think that the rest of the code would make up for that.

Looking forward to getting more details on this.

--- bill