Re: [AD] DO_PARALLELOGRAM_MAP again |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On September 16, 2010, Peter Wang wrote:
> On 2010-09-15, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > On 2010-09-12, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > > On 2010-09-11, Pavel Sountsov <slabode@xxxxxxxxxx> wrote:
> > > > Anyway, it's not like the drawer from the primitives addon is fatally
> > > > slower... it is slow for two reasons: it uses function pointers
> > > > instead of macro inlining; it uses al_put_pixel calls instead of
> > > > direct memory writes. Both can be fixed in short order, but as you
> > > > can imagine they make the development of those functions harder...
> > > > (which is the very problem of parallelogram_map) so I did not do
> > > > them. If that drawer becomes used for all bitmap drawing, it won't
> > > > be a problem to speed it up via some macro work.
> > >
> > > Yes, I see. With this quick hack `ex_blend_bench 3' is nearly as fast
> > > as `ex_blend_bench 2' on my machine. Restoring the commented out lines
> > > in fix_var makes it about twice as slow.
> >
> > al_draw_prim should be acceptably fast now. So do we move al_draw_prim
> > (and other "Low level drawing routines") to the core, or the whole of
> > the primitives addon?
>
> Answering myself again: once you move al_draw_prim and all the files
> required to implement it, only high_primitives.c remains. So there is
> not much reason to keep a separate primitives addon.
>
> I will wait for an okay to make this change.
I always wondered if it shouldn't be part of the core. Especially since it
seemed to do a lot of its own platform specific work that the core could have
done, but there was probably no interface to allow for.
> Peter
>
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx