nanogui@linuxhacker.org

It depends on your implementation.  First of all GrArea is pretty 
dangerous to use, because you are writing out hardware specific 
information.  It might work on X11, but port it to a Ipaq and you've got 
issues.   But beyond that, GrArea isn't a blit, so you will be slow, 
especially on an X11, since they will be actually doing the drawing in a 
similar manner. 

The better plan is to draw the image to a offscreen pixmap, and then 
GrCopyArea  the area over.  Its fast and inexepnsive, because you draw 
once and copy many times.   GrCopyArea is a blit, so it is super fast.  
I have ported over several image  programs (like XPenguins), and the 
GrCopyArea is as fast as I need to have half a dozen penguins climbing 
all over the screen.

Scott Robison has written some super cool image drawing code for FLNX.  
Its checked in right now, I would suggest that you give it a try. 

Happy hacking!
Jordan

karl wrote:

> Why is GrArea so slow??
> 
> I try to fix fl_draw_image() in flnx, its very slow,
> it make a for(x)for(y)GrPoint();
> so when I going to draw my 800x250 big image in RGB,
> it take some time (10-15 seconds). So I try to exchange
> the many GrPoint() for 1 GrArea()
> but I isn't getting any better why???
> 
> Regards,
> 
> 
> --
> ----------------------------
> Embedded RT System Developer
> 
> Karl Janmar
> Svensk ByggnadsGeodesi AB
> Kvarnbergsvägen 27
> 141 45  HUDDINGE
> SWEDEN
> 
> Phone: +46 (0)8 7112090
> Fax: +46 (0)8 7112098
> Homepage: http://www.sbg.se
> E-mail: karl@sbg.se
> ----------------------------
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org
> For additional commands, e-mail: nanogui-help@linuxhacker.org
> 
> 
> 
>