[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree86-devel
Subject:    RENDER and GLX in Xnest/nxagent
From:       Gian Filippo Pinzari <pinzari () nomachine ! com>
Date:       2003-04-18 17:01:23
[Download RAW message or body]

Hello there,

I have some questions. Sorry if they were already answered.
I checked the archives but could not find any reference.

-  We are extending Xnest/nxagent to support RENDER. We
   hooked Xnest to RENDER in mi and now RENDER extension
   is recognized by clients and functions appear to be mapped.

- Obviously, as no implementation in ddx exists, the requests
  do not produce any result on the real display. Strangely
  enough, anyway, we don't get any error. Does is testify the
  really good implementation of RENDER infrastructure or it is
  just that we are not actually doing any real RENDER
  operation :-)?

- We are on the long way to understand which priv must be stored
  in  Xnest to be able to remap Pixmaps, Windows and any other
  RENDER object that needs to be remapped. We are making a
  lot of guesses. Is there a document where we can find some
  hints?

- Is there any existing work done on RENDER and GLX in Xnest?

- I can be wrong but I remember that until XFree86 4.1.0 (or it was
  4.0.3) applications where not complaining about RENDER and
  GLX being missing. Exactly the same applications started to
  report this at the time we upgraded our tree to 4.2.0. I can't find
  a backup and I think I'll download an old XFree86 version in the
  next days, just to check what happened. For sure I used to run
  Morph3D screensaver to test image compression until it ceased
  to work :-). The previous build trees were at least able to let
  applications revert to software emulation. Now both QT and GTK
  fail horribly. Any idea on how we can improve this?

Regards,

/Gian Filippo Pinzari.

_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]