SRAM vs SDRAM as display buffer
SDRAM is transaction based; all accesses are burst based and therefore you will always have to use up a transaction period for all accesses. The part you link to can do a single read / write access (burst of one), but there are other overheads.

When I say transaction based, it means that there is more to a read or write than asserting that single command.

SDRAM accesses consist of opening a row, followed by a read or write command, then you need to wait for sufficient cycles to meed the CAS latency requirement; only then does the actual transaction take place. It is usually possible to continue to access a row without reopening it, but only until the refresh period has expired after which the row must be closed and then reopened.

Note that if you need to access truly random locations (in different rows) you will incur the row opening overhead for each and every row.

For video framebuffer applications, this will very likely be an overhead you will not want to have. 

In addition, SDRAM will do refresh cycles to meet the overall refresh timing requirements, making accesses somewhat non-deterministic

The SRAM you link to has none of the transaction timing issues above; the total cycle time (for the actual data transaction) is 20 nsec (min), but in many applications the actual throughput of an apparently slower SRAM is higher than SDRAM.

You need to analyse the data throughput requirements, and how the data are stored in memory to see just what real throughput you will achieve,