Did number of time a new window is refreshed on display decrease - initial missing text seen commonly
Tim, Darrell,
I recall discussion earlier about optimizations applied to R14. Did any of those have to do with the number of times a toolbar or menu is drawn or refreshed on first display? I ask because I am seeing a lot of text that is either missing or cut-off when a kcontrol app, or menu is displayed.
The text headings in the individual kcontrol apps and pop-up config items are the worst. When you first open a config applet the top-half of the text is for the block titles. For example:
open 'konqueror --profile filemanagement' (or 'Personal Files' on taskbar) The first block of options contains radio buttons for 'color' or 'picture' the block title for that group is 'Background'. When that dialog is first displayed, the top part of 'Background' is missing like it got clipped when the next element was drawn -- and then was never refreshed a last time to insure the entirety of all elements were visible. I don't ever recall seeing this behavior in the past and comparing to an older 3.5.13-sru install -- that does not occur.
Another area is menu entries. Open kwrite and open the 'Edit' menu. When I first to this the Ctrl+G 'Go To' line contains nothing but the underscore and the Ctrl+G tooltip:
" _ Ctrl+G "
I just clicked it again and this time the "Overwrite Mode" text disappeared leaving only the 'Insert' tooltip on the right-side. An time focus changes, the text is restored (both in kwrite, kcontrol, etc..) Since a focus change (which I guess forces a redraw) corrects the issue, it makes it almost impossible to capture with ksnapshot.
I have nothing concrete, but the feel I get is that some type of optimization fix was done to prevent TDE from redrawing a menu or applet one or two more times after initial display. I don't know if that is it, but it just feels like the elements are 1 redraw or refresh away from being ready when they are first displayed.
You guys think about this and let me know where to go with it...
On Thursday 30 of January 2014 15:31:00 David C. Rankin wrote:
Tim, Darrell,
I recall discussion earlier about optimizations applied to R14. Did any of those have to do with the number of times a toolbar or menu is drawn or refreshed on first display? I ask because I am seeing a lot of text that is either missing or cut-off when a kcontrol app, or menu is displayed.
The text headings in the individual kcontrol apps and pop-up config items are the worst. When you first open a config applet the top-half of the text is for the block titles. For example:
open 'konqueror --profile filemanagement' (or 'Personal Files' on taskbar) The first block of options contains radio buttons for 'color' or 'picture' the block title for that group is 'Background'. When that dialog is first displayed, the top part of 'Background' is missing like it got clipped when the next element was drawn -- and then was never refreshed a last time to insure the entirety of all elements were visible. I don't ever recall seeing this behavior in the past and comparing to an older 3.5.13-sru install -- that does not occur.
Another area is menu entries. Open kwrite and open the 'Edit' menu. When I first to this the Ctrl+G 'Go To' line contains nothing but the underscore and the Ctrl+G tooltip:
" _ Ctrl+G "
I just clicked it again and this time the "Overwrite Mode" text disappeared leaving only the 'Insert' tooltip on the right-side. An time focus changes, the text is restored (both in kwrite, kcontrol, etc..) Since a focus change (which I guess forces a redraw) corrects the issue, it makes it almost impossible to capture with ksnapshot.
I have nothing concrete, but the feel I get is that some type of optimization fix was done to prevent TDE from redrawing a menu or applet one or two more times after initial display. I don't know if that is it, but it just feels like the elements are 1 redraw or refresh away from being ready when they are first displayed.
You guys think about this and let me know where to go with it...
After updating from 3.5.13.2 to R14.0.0 (nightly-builds) I also noticing some problems in rendering. See bug http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=1693
Slavek --
On 01/30/2014 11:59 AM, Slávek Banko wrote:
After updating from 3.5.13.2 to R14.0.0 (nightly-builds) I also noticing some problems in rendering. See bug http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=1693
Slavek
Thanks Slavek, that what I was looking for. It's kinda annoying...
On 01/30/2014 12:12 PM, David C. Rankin wrote:
On 01/30/2014 11:59 AM, Slávek Banko wrote:
After updating from 3.5.13.2 to R14.0.0 (nightly-builds) I also noticing some problems in rendering. See bug http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=1693
Slavek
Thanks Slavek, that what I was looking for. It's kinda annoying...
Slavek,
I don't know if this is related to the issue, but on logout, if you move your mouse over the buttons on the shutdown dialog, the tooltips stack up behind the mouse and do not get repainted leaving you with a deck-of-cards looks on the right side of the dialog. If you 'Cancel' the shutdown, then all tooltips are removed when the window is repainted. If you have any ideas what to check, let me know. I'll try turning SAK off and see if that help.
On Friday 31 of January 2014 00:11:49 David C. Rankin wrote:
I don't know if this is related to the issue, but on logout, if you move your mouse over the buttons on the shutdown dialog, the tooltips stack up behind the mouse and do not get repainted leaving you with a deck-of-cards looks on the right side of the dialog. If you 'Cancel' the shutdown, then all tooltips are removed when the window is repainted. If you have any ideas what to check, let me know. I'll try turning SAK off and see if that help.
No, this is different. This problem was already in 3.5.13.x - under the dialog box is displayed an image that is not redrawn (darkening of desktop content is a static image). Therefore, after hiding tips will remain displayed its part above background image.
Slavek --
-
David C. Rankin -
Slávek Banko