> This is already being done in the Cairo code for certain operations
> where possible. Do you have a case where cairo is generating a large
> amount of overhead?
Well I did not test any specific benchmarks nore do I have relyable
testdata - but gtk applications just "feel" slower when running o
Clemens Eisserer ([EMAIL PROTECTED]):
> > When you draw a line or a curve using cairo, it is decomposed into
> > trapezoids which are rendered by RENDER.
>
> Sorry if this question is quite naive, but I wonder why cairo seems to
> generate such a large amount of overhead at all - why can't simple
Clemens Eisserer wrote:
When you draw a line or a curve using cairo, it is decomposed
into trapezoids which are rendered by RENDER.
Sorry if this question is quite naive, but I wonder why cairo seems to
generate such a large amount of overhead at all - why can't simple
operations like fills and
> When you draw a line or a curve using cairo, it is decomposed
> into trapezoids which are rendered by RENDER.
Sorry if this question is quite naive, but I wonder why cairo seems to
generate such a large amount of overhead at all - why can't simple
operations like fills and blits which are the mo
Rob Taylor ([EMAIL PROTECTED]):
> You'll have to excude me for not having followed much cairo/X work for
> a while, but does that ' --- ---' imply that cairo is
> rendering lots of traps using the RENDER extension?
Yes. When you draw a line or a curve using cairo, it is decomposed
into trapez
On Fri, 2005-06-10 at 09:33 -0400, Owen Taylor wrote:
> On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote:
> > Since everybody is talking about how glitz will eventually speedup
> > drawing operations by using hardware accelerated OpenGL, i built it
> > and then rebuilt cairo so cairo wi
Since everybody is talking about how glitz will eventually speedup
drawing operations by using hardware accelerated OpenGL, i built it
and then rebuilt cairo so cairo will detect glitz and compile with
support for it.
How does glitz further integrate into the desktop stack? Can i make
gtk+ use gli
On Wed, 2005-06-15 at 11:16 +0100, Rob Taylor wrote:
> On Fri, 2005-06-10 at 09:33 -0400, Owen Taylor wrote:
> > On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote:
> > > Since everybody is talking about how glitz will eventually speedup
> > > drawing operations by using hardware accelera
On Fri, 2005-06-10 at 09:47 -0400, Luis Villa wrote:
> On 6/10/05, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> > On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote:
> > > On 6/10/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > > > > > I haven't seen this announced on gtk-devel or here, so:
> > >
On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote:
> Since everybody is talking about how glitz will eventually speedup
> drawing operations by using hardware accelerated OpenGL, i built it
> and then rebuilt cairo so cairo will detect glitz and compile with
> support for it.
>
> How do
On 6/10/05, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote:
> > On 6/10/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > > > > I haven't seen this announced on gtk-devel or here, so:
> > > > >
> > > > > http://gtkperf.sourceforge.net/
> > > > >
> > >
On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote:
> On 6/10/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > > > I haven't seen this announced on gtk-devel or here, so:
> > > >
> > > > http://gtkperf.sourceforge.net/
> > > >
> > > > Apparently this is a test tool to test gtk performance. Would be g
On 6/10/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > > I haven't seen this announced on gtk-devel or here, so:
> > >
> > > http://gtkperf.sourceforge.net/
> > >
> > > Apparently this is a test tool to test gtk performance. Would be great
> > > to have someone test 2.7 with it.
> >
> > Went ahead a
On Fri, 2005-06-10 at 09:21 -0400, Luis Villa wrote:
> On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > > On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote:
> > > > On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote:
> > > > > If
On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> > On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote:
> > > > If we're talking about performance/stability in the context of
>
On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote:
> On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> Went ahead and did it myself. TextView is brutally slower (300-400%),
> some other things are 25-30% slower, and some things actually get
> faster. Disclaimer: I'm pretty sure I did this right
On Thu, 2005-06-09 at 15:12 -0400, Luis Villa wrote:
> I should have mentioned that this was with N=1000; jkh, I'm assuming
> you did the default n=100?
Correct.
If anybody is interested, here are numbers over remote display. The
network is 802.11g wireless LAN, ping time 1.3 ms. N still 100.
J
On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote:
> > first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of
> > yesterday, both with the Mist theme:
> >
> > GtkEntry - time: 0.43 0.76
> > GtkComboBox - time: 12.61 15.30
> > GtkCombo
On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote:
> first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of
> yesterday, both with the Mist theme:
>
> GtkEntry - time: 0.43 0.76
> GtkComboBox - time: 12.61 15.30
> GtkComboBoxEntry - time: 11.95 13.25
> GtkSpinButton - time: 0.65 1.09
On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote:
> > > If we're talking about performance/stability in the context of
> > > whether
> > > GNOME 2.12 should use GTK+ 2.8, we're e
On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote:
> > If we're talking about performance/stability in the context of whether
> > GNOME 2.12 should use GTK+ 2.8, we're effectively saying "I think the
> > GTK+ team might ship a unstab
21 matches
Mail list logo
