[Top][All Lists]

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

Re: [Traverso-devel] new themes

From: Remon
Subject: Re: [Traverso-devel] new themes
Date: Wed, 15 Aug 2007 14:43:14 +0200
User-agent: KMail/1.9.7

> Thanks. The default theme looks nicer, but due to the white backgrounds
> everywhere I find it hard to identify the different regions.

Yes, that's a problem. The gray-gradient-clipbackground works very nicely! The 
trackpanel however looks less good imo, but I'm sure you'll tweak that some 
more ;)

> > > P.S. They only work with CVS, not with the stable 0.41.0 release.
> >
> > Oops, faster faster Remon, fix that recording stuff, we need a new
> > release
> >
> > :D
> 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 
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!

> > One thing that again becomes clear is that my screen has a much higher
> > contrast then many other (TFT) screens, the name medium-contrast only
> > applies
> > when I set the "adjust-theme-color" to 115% !
> >
> > But since most screens seem to have lower contrast by default, it's
> > perhaps
> > better to just ignore me and my screen LOL :D
> Hey, we can have as many themes as we like. Should I make a "medium
> contrast for Remon's screen"?

LOL, yeah good idea!

But of course, more themes to choose from is great, that's after all part of 
the idea behind making an application themeable !

> We could also add a galery to the website. 

Absolutely! People love screenies (I do at least)

> > 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]



Although it's about EXA, it does show some performance measures too for XAA, 
the default acceleration used in xorg:

reply via email to

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