Video memory writing usually is slower than computer memory. If you use
video memory for drawing operation you have to pay for it.
For example software alpha-blending in video memory is usually slower than
the same operations in usual memory, but software blit from usual memory
take more than page flipping and copy from video to video memory.  So there
is no true answer for all combination of drawing operation. Also we have to
take in account using of accelerated functions. But often those functions
are slower than software equivalents.
Dmitry Semenov
-----Original Message-----
Sent: Saturday, January 29, 2000 03:11
Subject: Re: fastest output

Andreas Beck wrote:
> > what about a memory visual using video memory ?
> This can be done by using e.g. the "sub target" on a main visual with a
> larger virtual area

I don't understand. You ask me to allocate a larger visual and then to use
the bytes currently not visible for my other purposes ?

I think that is a bad idea. First of all, I don't know how many extra
buffers I need. This is all dynamic. If a client connects to the server
and asks for a graphic he can run his quicktime movie in, I want to back up
everything behind and in front of it so I don't need to traverse the scene
graph each time a new frame is rendered into this video graphic.

In other words, the number and size of drawables I might want to allocate
are completely arbitrary and only known at run time. Therefor I want a
'drawable manager' which is responsible for (V)RAM allocation and
on demand. This might be more in line with what you refer to as an
I just want to remind you that we are (will be) quite keen on this.


Stefan Seefeld
Departement de Physique
Universite de Montreal


      ...ich hab' noch einen Koffer in Berlin...

Reply via email to