|Re: [AD] iOS multiple screen support plans|
[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
On Sat, Oct 22, 2011 at 1:08 AM, Trent Gamblin <trent@xxxxxxxxxx>
The events are pretty self explanatory. The flag makes the iOS port (and some portions of the base library and OpenGL driver) behave like the d3d driver. When a bitmap is locked or set as the target, it's marked as dirty. Bitmaps with this flag have a non-null bitmap->memory pointer which holds the bitmap data in system memory. When the display is flipped, dirty bitmaps with this flag are backed up to system memory.
Won't this eat up quite a bit of memory, especially on ios?
Irrelevant unless there's another way. And it only does so if you ask it to. Since this feature is only available on iPad and iPhone 4s you have plenty of memory.
There are performance issues if you use this, but in my tests with a game that uses hundreds of bitmaps, it doesn't appear to slow anything down much on a 1st generation iPod touch.
How many of those bitmaps are marked dirty each frame?
Not many. I think it's typical of an OpenGL game. Bitmaps that are drawn to are usually buffers or "work" bitmaps and those don't need the flag because they're updated each frame.
The reason for the need for the system memory backups is that a display can be detached at any time without any notice which immediately invalidates the graphics memory (or so it appears in my tests, which is why I added this flag after writing the rest and finding my images were all corrupt after unplugging a screen.)
Is the OpenGL context re-created or something? I don't really see the connection between plugging in a device and the OpenGL state... I must be missing something.
A new EAGLView is created for each ALLEGRO_DISPLAY.