Colors - Performance impact of non-equal inactive and active palettes

Matthew Woehlke mw_triad at users.sourceforge.net
Tue Dec 4 16:00:24 GMT 2007


Aaron J. Seigo wrote:
> On Monday 03 December 2007, Matthew Woehlke wrote:
>>> as you note, kde3 is the same here so it's not a regression for kde. we
>>> can and should catch up with others, but i think we have enough other
>>> cool stuff that this is not a critical feature and it would be a crying
>>> shame to have such an impact on our performance just to toggle one set of
>>> colours. it just isn't worth it.
>> I just fear that if the default is off, it will stay off :-(. I've been
>> there.
> 
> if a default stays off, that's due to a lack of due diligence on the part of 
> the responsible developer(s), nothing more. if there is a good reason for 
> turning it off, then addressing that reason will be the signal to turn it 
> back on. it's pretty clear to me =)

Maybe. But I hope you can understand that my past experience with what I 
see as similar changes was... less than pleasant.

>> But, as I say, making it depend on the system would be OK, that way
>> modern systems that can handle the load aren't "penalized". Thoughts?
> 
> how would you discover this? and "handle the load" would, at least imo, 
> mean "fast enough that you can't tell the difference between a Qt4, KDE4 and 
> Gtk2 app .."

Well, if/when we actually export our colors, Qt4 and KDE4 will be the 
same. Actually, Gtk2 already seems sluggish here, so it may be they are 
just as bad now as KDE4 would be... room for improvement from us/TT :-).

I would define "fast enough" as "any delay is short enough to be hardly 
noticable and/or not disruptive". This would presumably be based on CPU 
speed, as determined by Solid of course.

(Methinks it's too bad we don't have our first-run tool any more :-(...)

D'oh, incidentally, I just realized one obvious performance tweak; if 
only the selection colors differ, the widget only needs to be repainted 
if it previously had focus. Otherwise, assuming it is not broken, it 
should have been using inactive selection colors already. (Again, there 
is probably need for a widget to be able to override this behavior, but 
this change might be possible in the shorter term.)

-- 
Matthew
<punchline removed due to distasteful content>





More information about the kde-core-devel mailing list