|
Locking bitmaps is very slow |
Bruce Pascoe
Member #15,931
April 2015
|
This is something I've noticed: Locking a bitmap under Allegro is very slow. For video bitmaps this is expected, as the texture data has to be downloaded from the GPU and then re-uploaded, however it's been my experience that, even with memory bitmaps, calling al_lock_bitmap is very expensive when you would expect it to be instantaneous as the bitmap data is already in main memory. edit: Nevermind, disregard: Turns out I screwed up the bitmap flags and was actually creating video bitmaps after all. Oops. Just to clarify, I use memory bitmaps in some places because performing pixel-level manipulations on them is fast, so they can be used to compose an image in software (using color matrices, etc.) and then convert it to a video bitmap once it's done.
|
Edgar Reynaldo
Major Reynaldo
May 2007
|
For video bitmaps, you can lock it WRITE_ONLY, which should only allocate a memory copy to be uploaded later, or READ_ONLY, which should only download the texture data. At least that's what I would expect Allegro to do. As for memory bitmaps, I agree, ideally it should only return a pointer to the data, which should be instant. I'm not familiar with allegro's internals though, so I can't say what it really does. Edit My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Bruce Pascoe
Member #15,931
April 2015
|
No, locking memory bitmaps actually does seem to be fast, at least al_lock_bitmap() stopped showing up on the hot-path in the profiler once I fixed the flags. What IS slow is you try to al_draw_bitmap() a memory bitmap directly (without conversion), which seems fair enough.
|
|