Re: [AD] al_put/draw_pixel() speed |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, 2009-08-08 at 10:50 -0700, Paul Suntsov wrote:
> > My understanding always was this:
> >
> > al_draw_pixel:
> >
> > * normal drawing function like al_draw_line and so on
> > * always accelerated
> > * illegal to use on locked bitmaps
>
> How do you do blending on locked bitmaps then? This must be possible
> for the primitive addon to work, otherwise it will need to implement
> al_draw_pixel that is allowed on locked bitmaps.
You don't do any drawing on locked bitmaps... they are for accessing the
raw pixel data. So when you use any blended drawing operations the
bitmap will not be locked.
> Moreover, some people (Trent G. iirc) reported that locking the
> bitmap before calling a lot of al_draw_pixels was more efficient than
> not locking and using the hardware accelerated al_draw_pixel.
>
You can do that by blitting the bitmap to a memory bitmap, do your
al_draw_pixels calls in the memory bitmap, and finally blit it back.
Basically do explicitly what Allegro otherwise would have to do
internally anyway. Most likely it would even be faster if you do it
yourself as you can keep your memory bitmap around instead of having to
allocate a new locked region each time.
If we would want to allow drawing to locked bitmaps, then we should not
route such operations to the display driver at all. Instead it would
strictly be a software-only operation, operating on whatever region of
the bitmap is locked (so there's now another indirect clipping
rectangle) and happen in whatever pixel format the bitmap is locked to.
This means that at least driver implementors could assume bitmaps are
not locked (if it is locked they'd have to call back to the software
routines anyway, so pointless).
Right now, none of this is implemented though. Myself, I wouldn't mind
if someone does it - a code re-factoring pass over the bitmap code
wouldn't be bad anyway :) However, I don't see anything which would get
possible with it which isn't already, from a user perspective.
--
Elias Pschernig <elias@xxxxxxxxxx>