[BColorControl] flickering and cpu eater

[diver]

It most noticable in Menu pref. Start Pulse. In Menu open Select Color Scheme and start to move sliders and you will see much flickering and in the same time it will eat all your cpu time.

[cl21]

Only the rectangles containing the selectors are invalidated on color change. Reduces the flickering.

[jackburton]

I'll apply the patch. Thank you for your work!

[jackburton]

I've applied the patch in hrev23192. The bug is fixed. Thank you!

[diver]

Reopening as some flickering remains while moving slider. Also cpu usage still the same (~100%). Tested under vmware on linux with hrev23367.

[aldeck]

I'm working on a patch for BColorControl (see #1701), i'll have a look at this. If i'm not wrong, the color ramps redraw doesn't take into account the update rect.

[jackburton]

What do you think about having the color ramps cached in the offscreen bitmap, and the selectors drawn directly on the view ?

[stippi]

+1!

[aldeck]

Definitely! I could do it :) But i'm a little perplex right now :

I've implemented partial redraw of the ramps, but didn't get enough performance gain. I've looked at the code of BSlider, it doesn't (as of now) use an offscreen bitmap (ifdefed) but is much more responsive under system load. I wonder if there isn't a mouse tracking issue that would cause a lot of unnecessary redraws. Also, since i was mostly testing trough prefs/Menu/ColorScheme, there might also be a slowdown due to the sample menu updates (changing menu color in real time).

I also investigated why do we see the invalidate rect in white when moving fast. I tried everything, without success...

Unfortunately i won't have much time this week.. I'll keep you updated :-)

[aldeck]

jackburton: Your last commit, hrev23518 "using B_NO_POINTER_HISTORY in SetMouseEventMask()" did the trick for the cpu eating issue. It's now much more responsive even under load, even without offscreen drawing.

I've got a patch, almost ready for submission, which implements the 8bit palette mode and corrects other minor issues. I need to reimplement offscreen drawing since i postponed the question until the palette mode was finished. (optimize only when everything works :) ) BColorControl only lacks keyboard navigation now!

[jackburton]

Replying to aldeck:

jackburton: Your last commit, hrev23518 "using B_NO_POINTER_HISTORY in SetMouseEventMask()" did the trick for the cpu eating issue. It's now much more responsive even under load, even without offscreen drawing.

Ok, that's good. I didn't do extensive testing after that, it seemed that the cpu was still under heavy load when moving the mouse too fast, although at least the control didn't lag anymore. B_NO_POINTER_HISTORY is a must for most controls anyway.

I've got a patch, almost ready for submission, which implements the 8bit palette mode and corrects other minor issues. I need to reimplement offscreen drawing since i postponed the question until the palette mode was finished. (optimize only when everything works :) ) BColorControl only lacks keyboard navigation now!

Very nice! Thank you for your work! Just attach the patch here when it's ready, and I'll apply it.

Shall we keep this bug opened ? And what about #1701 ? I'm for closing this and track #1701 since it holds a better description for the various tracking issues.

[aldeck]

Replying to jackburton:

Shall we keep this bug opened ? And what about #1701 ? I'm for closing this and track #1701 since it holds a better description for the various tracking issues.

Yes, although there's still the invalidate rect that flickers a bit, close it and let's move on to 1701 :)

[jackburton]

Closing. The remaining bugs will be tracked in #1701