| Re: [AD] About the speed of flat polygon primitives |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
>> Get your conclusions here...
>
>Which primitives are hardware-accelerated by the BeOS HW-accel driver ?
>I suppose that putpixel(), ellipse(), arc() and textout() are not, so why is
>there a gap ?
The test was done in 640x480x8, and accelerated features are only rectfill
(and thus hline and vline as they use hw rectfill with width/height of 1, as
well as clear_to_color) and VRAM->VRAM blit.
I dunno about the gap. The first thing that comes to mind is the call to the
sync function done at line-switchers level when there's something
accelerated... The same applies to the DGA2 driver; calling this function may
slow down things, but frankly I don't know if it's the real cause.
>Same question for the DGA2 driver (see my message dated 09/29): why is there
>such a gap for line(), circle(), ellipse(), arc() and textout() ?
See above. And I'm sorry but I can't investigate it at the moment as I've
uninstalled Linux due to a repartitioning (installed Virus XP - which keeps on
crashing for me within 10 minutes since startup; luckly I've another partition
with BeOS)
>My patch will likely accelerate circlefill(), ellipsefill() and triangle()
>for the HW-accel driver so that the gap will narrow for them.
Let's hope! The results for DirectDraw were promising...
>Finally there is the hline() problem: it seems that on modern machines
>(that's not the case for my P200), the HW-accel hline() is much slower than
>its software counterpart because the 2D engines of video card are obviously
>lagging behind the CPU power/AGP speed combination. Should we disable
>hardware acceleration for hline() ? On all machines ? On fast machines only,
>using some heuristic trick (cpu_family > 5 for example) ?
Well, the accelerated hline function IMHO is primarly meant to be used several
times after calling acquire_bitmap(), so the system already locked the bitmap
and the lines get drawn quickly. This works best only if multiple lines are to
be drawn on a pre-locked surface, otherwise it's not hard to figure out that
the program slows down. Unluckly the multiple lines case is not that common,
so the slowdown happens in most cases... I don't think we should modify the
current behaviour thought, expecially if we implement the hfiller method for
the filled primitives. Maybe a word of warning in the docs would help...
--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com