[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
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!
> > 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]
Greetings,
Remon
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/