On Tue, Mar 07, 2000 at 11:36:34PM +0100, Marcus Sundberg wrote:
Somebody said the "proper" way to resize a window in GL involved shutting
down the GL context, resizing the window, then recreating it. Perhaps
this is to get around software bugs, but it sounds like a royal PITA to
deal
+AC_SUBST(DLLEXT)
hehe ... you also got it ? Marcus too :-). Three hours ago ... :-). It is
fixed in CVS now ... I had a clash when checking my fix in - Marcus was
faster ... :-).
CU, Andy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Hi !
I'm interested in also setting up Z
and alpha buffers. How would I go about doing that ?
Basically same thing ... add a function to allocate them to the kernel
driver and them mmap. We should talk about a generic API for requesting
such extra features, though.
No mmap.
Hi !
hardware auxiliary buffer, you will either need to have a kernel driver
which can let userspace mmap() the physical aperture, or do some suid-root
Neither. The SGI approach of not mmaping these buffers.
This only works for the nice SGI hardware. I perfectly agree, that it has
huge
[EMAIL PROTECTED] writes:
Do I have to repeat a single e.g. line drawing call,
I cannot recommend that, unless you have a very very powerful accelerator and
a very very weak CPU or are low on RAM.
If not, I'd draw the window (which is what you are hinting at - right ?) into
RAM and
[EMAIL PROTECTED] wrote:
OK. Especially if LibGGI2D is oriented towards hardware acceleration,
complex clipping should not be too much different from hardware chipsets
capabilities.
Yeah. It might make sense to implement a simple z-buffer operations thingy
or similar for LibGGI3D and
Hi !
I don't think LibGGI2D should have arbitrary clipping. I'd leave that to
a windowing library or a 3D package.
I understand. But I asked this question in the first place because I don't
feel totally at ease with the way I/we do clipping over regions
On Tue, 7 Mar 2000, Andreas Beck wrote:
Currently the "triangle drawing" extension library which most people use is
of course GGIMesa, but LibGGI2D has triangle drawing functions as well,
and of course there is always LibGGI3D.
I'd say either rewrite LibGGI2D and add it (rewrite, to
On Tue, 7 Mar 2000 [EMAIL PROTECTED] wrote:
Hi !
GGI - as far as I know - has only a notion of a rectangular clipping
rectangle being valid for all subsequent primitive drawing calls.
Yes. This is due to the fact, that there are only two methods I have seen to
do clipping in Hardware:
On Tue, 7 Mar 2000, Rodolphe Ortalo wrote:
On Sun, 5 Mar 2000, Andreas Beck wrote:
(as an answer to this question from myself)
Should libggi2d support arbitrary clipping - or would it be acceptable to
have a 'small' version with only rectangular clipping ? (But with decent
drawing
On Tue, 7 Mar 2000, James Simmons wrote:
I'm interested in also setting up Z
and alpha buffers. How would I go about doing that ?
Basically same thing ... add a function to allocate them to the kernel
driver and them mmap. We should talk about a generic API for requesting
On Wed, 8 Mar 2000, Thad Phetteplace wrote:
Hello All,
I am curious what the status of harware accelerated 2D graphics
on GGI is.
The same as it has been for a long time now |-/. The basic 2D
functions in LibGGI are accelerated on most targets which support 2D
acceleration, and
Hi! everyone:
I'm new to GGI. I have some question.
Where can I find the information of GGI?
Will Libggi work, if I don't install KGI?
What are the relations between GGI, KGI and XGGI?
ps: I'm not good in speaking or writing English. If I seems to be impolit,
I'm sorry.
13 matches
Mail list logo
