Here’s another idea:
Render your background on 512x512 chunks. During the draw() function, you only render 4 chunks, in addition to dynamic elements (monsters, doors, etc.)
As your character moves around the map, you pre-render new chunks just outside of the character’s field of view and discard chunks that are no longer necessary.
There’ll be some small lag while chunks are generated, but if you throttle the process so that it only generates one chunk at a time, you can keep the frame rate up and still make the world as massive as you want.
@Slashin8r whoops good point on the clip function 
I here’s another idea, not sure if it will work, how about render your background mesh(s) once to an image and then use another mesh which has a single rect the size of the screen and then set the background image to the texture. Then to scroll with the player offset the position of your background texture with setRectTex. Though of course with this approach there will be some tiling and other management needed for backgrounds larger than the maximum image size and this only in theory works for non-dynamic elements.
@toadkick and @tomxp411, I think loading in chunks would be a great way to resolve this. I will definitely look further into this. I really like this idea since it will guarantee that even large maps can be viewed cleanly and read through easily on a small screen such as an iPad. The 2D grid table for the large map I’m using for testing is impossible to read on the iPad. Split that map into chunks of let’s say 40x40 tiles would make it easy to decipher. The most tiles that would be rendered at once would be 80x80, or 4 chunks, (the current large map I’m testing with is 130x80) which would cut out 4000 tiles which equals 16000 mesh rectangles (not including certain tiles that share the same location). That would definitely boost performance substantially.
@tomxp411, there are 5 map layers, 4 of which are being drawn. Floor tiles, animated tiles, object tiles, and decor tiles are all drawn. Then there is the “invisible” event layer.
Edit: On screen 33 tiles (32x32 in size) are displayed horizontally and I need a buffer of at least 1 on each side, so 35 tiles are needed. 25 tiles are displayed vertically and I need a buffer of 1 on top and 4 below (roof textures are 4 tiles tall), so 30 tiles are needed. So, I think I can make chunks to be 35x30 and everything will continue to look seamless (35x30 maps are generated very fast and at most 2 chunks will need to be generated at any given time).
Thought a bit more about the chunk idea and I think it might actually be best to generate all the chunk meshes of a map at once, but only draw up to 4 of them at a time. This way there only be one loading time when you first enter a new map and then no loading time for switching out chunks.
This is definitely going into my next update. Thanks for the brainstorm session everyone.
We’re here to help, man. Well, that and steal your ideas for our own programs… 
Actually, I’ve been working on an RPG engine, off and on, for several years, but I’ve scrapped it and started over. A big reason is that technology has completely changed, and with Windows 8, XBox One, and all the mobile devices out there, I’ve decided to start over.
One thing I’ve definitely figured out: building a good, flexible RPG engine is hard work. =)