On Fri, March 16, 2007 11:39, Felix Nawothnig wrote:
This fixes a glitch (blue text background inside a red selected cell)) in SuperGrid (http://flexo.popuserv.org/SuperGrid.exe) and appears to be what native does.
There is no need to use OPAQUE anyway since we always draw the selection background seperatly.
But this ends up creating and deleting the brush for each of the cells we draw... I'm not sure I understand why using OPAQUE here doesn't work.
Dimi Paun wrote:
But this ends up creating and deleting the brush for each of the cells
Well - yes. But other controls do this too (statusbar for example) and considering all the stuff we do during refresh this is hardly a bottleneck. And even if it is we should optimize this codepath in gdi32 instead (by caching solid brushs for example).
we draw... I'm not sure I understand why using OPAQUE here doesn't work.
Problem is that DrawText() for the subitems will also use the background color - which is wrong. To fix this while still using OPAQUE we'd need to do something like:
SetBkMode(OPAQUE); TextOutW(...); SetBkMode(TRANSPARENT);
But abusing TextOutW() like that just seems wrong to me.
Using DrawText() to draw the background won't work either due to LVS_EX_FULLROWSELECT (well, I guess we *could* do it by DrawText()ing the first item over the full row and the subitems on top of it but I'd prefer to _simplify_ the code, not add more hacks).
Felix
Felix Nawothnig wrote:
Well - yes. But other controls do this too (statusbar for example) and considering all the stuff we do during refresh this is hardly a bottleneck. And even if it is we should optimize this codepath in gdi32 instead (by caching solid brushs for example).
...looking at the statusbar code again I think using GetSysColorBrush() for the three default cases would be even better. If an app overrides the colors using CD performance will suffer slightly but that's Microsoft's fault by requesting a COLORREF and not a brush for each item.
Felix
-
Dimi Paun -
Felix Nawothnig