traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] new themes


From: Nicola Döbelin
Subject: Re: [Traverso-devel] new themes
Date: Wed, 15 Aug 2007 15:27:19 +0200
User-agent: KMail/1.9.6

On Wednesday 15 August 2007 14.43:14 Remon wrote:
> > Hehe, my words! Although I didn't change the way gradients are stored in
> > the theme file yet. (Remember? You suggested a different method, but I
> > didn't have time to implement it yet.)
>
> Ah yeah true. I think I've changed my mind about that a little, using QSVG
> would be way to difficult, but a somewhat more flexible way to describe
> colors and stop points to setup a Brush from the theme file would be a
> great solution.
> The stop points and colors then could be stored in some kind of struct, and
> requested on demand from anywhere. Or maybe even better, creating the Brush
> in Themer itself, so there is no code duplication!

Hm, sounds like I might need your help. How to store variable numbers of pairs 
of stop-point / color isn't clear to me.

> > > The gradient filled audioclips consume quite a bit cpu ....
> > > I'm afraid the only way to get rid of high cpu load is to use triple
> > > buffering, at least when moving clips around.
> > > Anyways, something for later :)
> >
> > I tried rendering the gradients to pixmaps before painting, but it didn't
> > help. (Re-rendering was only done when necessary, of course.) It seems as
> > at the moment only solid colours should be used.
>
> Hmm, how large pixmaps did you use? Using small pixmaps imposes a rather
> high overhead in the pixmap painting itself, the larger the pixmap, the
> more efficient the fillrate becomes.
> I.e. painting a pixmap of 100 * 1000 is way more efficient than painting
> 1000 times a pixmap of 100 * 1 [1]

I tried both very small ones (1 * height), and bigger ones (512 * height). 
Remember the screenshot with the pixmap texture filling the clips I sent you? 
These were relatively large, but I didn't notice a performance difference in 
both cases. When zooming in, painting became so slow that it was totally 
unusable, just as with the gradients buffered or painted directly.

Is it a Qt/Xorg problem? It seems to me that they should clip the repainting 
to the viewport, even at high zoom levels. Then zooming should not make much 
difference. I'm a bit surprised, because when they introduced the 
GraphicsView framework, they showed some very impressive and performant 
examples. But I have the impression that things like painting the playhead 
would be much more performant when using the "old" pixmap painting. Do you 
know if GraphicsView is still under construction? Will there be improvements 
in Qt 4.4?

> Although it's about EXA, it does show some performance measures too for
> XAA, the default acceleration used in xorg:
> [1] http://www.cworth.org/exa/what_exa_gets_right/

Thanks, I'll have a look at it.

Nic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]