Havoc Pennington wrote:
Another question is how the matrix stack would be done; client-side
matrix handling would be an opportunity to remove the limit on stack
depth by keeping an infinite (or much larger) stack in cogl.
Desirable?
The depth of the stack is imposed by your driver; my
I just got this working and figured I would share. I already had gtk2,
python25, py25-gtk, etc installed via MacPorts and hoped to find a way
to get pyclutter installed and running using my existing environment.
Clutter revisions:
clutter-0.8.4 (also tested with clutter-0.8.8)
Hi,
On Mon, Feb 23, 2009 at 3:26 AM, Tomas Frydrych t...@linux.intel.com wrote:
I do not particularly like this idea on principle, as you are moving
processing from GPU to CPU. Also, it feels like you are trying to
address driver brokenness in Clutter.
I would say the main win of the patch
On Mon, 2009-02-23 at 08:26 +, Tomas Frydrych wrote:
Havoc Pennington wrote:
Anyway, maintaining the matrix client-side does not look super hard
but it's mostly a series of matter of taste judgment calls so if
anyone could give some guidance on how to approach this... some early
On Sun, 2009-02-22 at 01:35 -0500, Havoc Pennington wrote:
Hi,
When using indirect rendering (I know, it's insane, but currently
needed for compositing managers), shoveling the matrix over the X
socket and occasionally pulling it back is turning out to be a pretty
bad problem.
Every
Hi,
On Mon, Feb 23, 2009 at 7:32 AM, Robert Bragg b...@o-hand.com wrote:
I'd personally be fairly happy with the flush type approach; but I'd
take the opportunity to add something like cogl_flush_gl_state() which I
think would tie into ideas we've discussed in the past about improving
the
Hi,
On Mon, Feb 23, 2009 at 7:32 AM, Robert Bragg b...@o-hand.com wrote:
The biggest disadvantage to dealing with the matrices client side looks
to be with tracking the inverse matrix. Calculating the inverse can be a
rather expensive operation, and at least looking at the Mesa code it's
Hi,
On Mon, Feb 23, 2009 at 7:32 AM, Robert Bragg b...@o-hand.com wrote:
Personally I wouldn't be so worried about this - at least not for the
same reason. I think there are good reasons why GLES 2.0 and OpenGL 3.0
scrapped the GL matrix stack APIs entirely. I don't think it's typical
for the
On Mon, 2009-02-23 at 08:09 -0500, Havoc Pennington wrote:
Hi,
On Mon, Feb 23, 2009 at 7:32 AM, Robert Bragg b...@o-hand.com wrote:
I'd personally be fairly happy with the flush type approach; but I'd
take the opportunity to add something like cogl_flush_gl_state() which I
think would
Hello,
I'm trying to implement a container in python.
I have something like this:
class Cont(clutter.Actor, clutter.Container):
__gtype_name__ = 'Cont'
def __init__(self):
clutter.Actor.__init__(self)
clutter.Container.__init__(self)
def do_add(self, child):
On Mon, 2009-02-23 at 08:12 -0500, Havoc Pennington wrote:
Hi,
On Mon, Feb 23, 2009 at 7:32 AM, Robert Bragg b...@o-hand.com wrote:
The biggest disadvantage to dealing with the matrices client side looks
to be with tracking the inverse matrix. Calculating the inverse can be a
rather
On Mon, 2009-02-23 at 18:27 +0100, Julien Pauty wrote:
Thank you very much for this example.
Is it normal that you don't call clutter.Container method?
yes: clutter.Container is an interface and thus has no implementation.
Like: clutter.Container.do_add(). If I don't call
12 matches
Mail list logo
