> > Well the reason the framebuffer suck is because the current api sucks for
> > them. It draws pixel by pixel. Slow slow slow!!! I have developed a new
> > api that takes advantage of the accel engine of graphics hardware. It is
>
> Great. VESAfb doesnt have one. Lots of older machines dont have one.
True. Of course VESAfb exist because we lack so fbdev drivers. In time
that problem should go away. Also many embedded devices, which I do for a
living, lack hardware acceleration. Well okay alot of modern PDA's are
staring to have accel engines. This doesn't mean you can't write really
good optimized software code for devices that lack hardware acceleration.
The software accel functions needed by the console layer (copyarea,
fillrect, and drawimage) have been already written. Okay the drawimage one
needs alot of work. I haven't benchmarked the new code versus the current
code but you can see the difference. One of the big changes I have have
made is that on write data to the framebuffer word aligned and a long at
a time. For 8bpp you have 4 pixels written at a time. This makes for a
much tigher loop. On ix86 you can see a huge difference in performance due
to the word alignment. I knwo because at first I had a bug that wasn't
doing it right. After I fix that bug you could see the difference.
We use the same techniques at work for embedded devices where the cpus
don't have the horse power like desktops. Every single line of code counts.
I haven't ported the assembly versions for different platforms yet but I
plan to. I know from experience writing proper assembly on ARM or using
MMX will increase preformance many fold.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:24 EST