[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Tue, 2005-09-13 at 23:12 +0200, Evert Glebbeek wrote:
> > But since this comes up relatively often, I guess our docs are simply
> > wrong. Attached patch describes better what it does, and also warns
> > about its use. I think most uses of it aren't necessary at all.. but the
> > current docs are like "use this to make your program faster", so that's
> > expected :P
>
> Well, isn't this a bit too much in the opposite direction? ;)
I don't think so. Typical Allegro newbies shouldn't use this function -
they will always end up calling show_mouse() or readkey() while a bitmap
is locked. Or maybe even do things like what I did back then when I came
to Allegro and pair up acquire_bitmap() with unlock_bitmap() :P
Besides, drawing directly to video bitmaps most often is not
appropriate:
- Either you use HW accel, in which case you shouldn't acquire at all.
- Or you use lots of separate memory drawing commands, in which case you
should use a double buffer.
> Also, acquire_bitmap() makes sense if blitting several *memory* bitmaps, as
> opposed to video bitmaps.
> But yes, a good listing of if and when it's useful was sorely lacking in
> the documentation.
>
Yes, but like my example 3, it's a gray area.. will you really benefit
much in general? The possible deadlock outweighs the minimal speed
increase. Of course, if you need to blit many small memory bitmaps to a
video bitmap, then you should manually call it.. but then you should
already know what you are doing as well.
Bob's auto-video-memory-bitmaps suggestion from some time ago also would
solve this nicely I think (although I have yet to see details how it
will work - especially as long as we only have immediate bitmap updates,
so no grouping of e.g. putpixel calls is possible).
--
Elias Pschernig