Re: DBE on nv, Shape and XAA questions

On Sat, 18 Jun 2005, Michal [iso-8859-2] Maru¹ka wrote:

> * Is it correct, that the "nv" driver does not support DBE (double buffer extension)?

   The drivers have nothing to do with DBE extension support.  XFree86
supports DBE for all hardware whenever you load the "extmod" module.
DBE is not supported in Xinerama, however.

>
>
> * How fast are "Screen to screen bit blits" ?

   Depends on the hardware.  Hardware blits are always significantly
faster than software blits.

>
> I tuned sawfish WM, so that when resizing windows it sets the border window (WM
> decoration) to a suitable window gravity, so it's up to the X server to move it
> correctly (WM does not redraw). I avoided shaped windows.
>
> I use the "mga" driver, so it has "Screen to screen bit blits" XXA call.
>
> Yet, if I resize (in 1 direction) continuously the window, i see the vertical
> line as a staircase line:
>
>
>    |        |
> b  |        |
> l  |       |
> a  | ->    |
> c  |       |
> k  |      |
>    |      |
>
> Any idea if it can be improved?

   Rendering is not synchronized with the screen retrace, so tearing
is expected.

>
> * Shape vs. flickering
>
> if i run xlogo -shape (resize it to make things clear) and move the logo window, i see
> flickering (the window below is obscured and redrawn even outside of the logo).

    We you move a window, the uncovered area needs to be redrawn, of
course.  When using the shape extension, exposures are not done down
to the pixel.  For performance reasons, it's exposing bounding boxes,
because every separate exposed rectangle is a additional call back
to the client.


>
> I would likt to know, if "Screen to Screen color expansion" XAA call could be used to
> avoid it.
>

   Everything is already fully accelerated.  Add Option "NoAccel" to
your Section "Device" in the XF86Config file to see what unaccelerated
rendering looks like.


			Mark.