From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Tue, 15 Sep 1998 20:29:32 +0200 (MEST)

Re: Graphics newbie

Hi and welcome on board !

> 1)  I've compiled and run the stars demo on libggi (since it shows frames
> per second), under X with GGI_AUTO sizing, it shows 30 fps, when I increase
> the size to say, 1024x768, it slows down dramatically to somewhere around 4
> or 8 fps.  What is the major contributor to this slowdown?  Is it:
> a)  Slow graphics card?  I have a TGA card running on a DEC UDB (multia)

No - not really. Especially for the stars demo running via the X target, other 
things are much worse.

> b)  X is just slow?  Would running kgi instead change this?  What sort of
> speed up?

It would speed things up a lot, but not really because X is a lot slower
than KGI, but because X is used suboptimally for that specific case of
stars.c

> c)  The X target is slow because it copies a whole XImage to the window
> each time ggiFlush is called?

Yes. This is a general limitation, which cannot be avoided with X. Though
we try to keep the overhead minimal by using XShm.

> d)  My X target is slow because it doesn't use X shared memory or the X
> double buffering extension?  I don't know anything about these other than
> they are supposed to speed up graphics under X

It should use the XShm extension. You can verify that with 
GGI_DEBUG=255 ./stars . SHould give debugging info, which should also
include indications if XShm is used.

> e)  Other?

stars.c is particularly slow via the X target, because it effectively draws
just a few dots but forces the X target to copy the whole framebuffer.
These are 768k for a 768x1024x8BPP modes.

If XShm is in use, X just needs to blit that between main memory and
card memory (not nice, too, but ...). If not, it has to push it _through_a_
network_socket_ ... that would really suck performance.

So for programs that don't draw much per frame, the Xlib target is much
better suited. You can turn it on using GGI_DISPLAY="Xlib::0.0" or something
like this.

> 2)  How do you directly access the data in a visual?  Is there some way to
> do something like memcpy(visual_data_ptr,image_data_ptr,count) ?  

Yes. DirectBuffer is here for that. You can ask LibGGI for a descriptor 
that tell you how the screen is laid out internally.

The idea is, that you check if there is such a buffer with a format your
application understands and then use it, if not, revert to the drawing
functions.

> A more general question:  Is there a  way to copy data directly into 
> video memory?

Yes. If DirectBuffer is supported by the target and you know its structure.
If not, you need to fall back to either ggiGet* ggiPut* or (better IMHO)
to opening a memvisual and using ggiCrossBlit();.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =