Vista - Fixing delays in UI response time

My application's responsiveness is getting really bad when the user
modifies a text box. There is a big noticable delay between the time I
enter a character and the time the control gets the focus back (and
displays the character).

Since a large team of individuals have been working on this project,
it's hard for me to pinpoint what went wrong. Is there a place somewhere
that I can use that would tell me where the code is between the
key-press event and the time it takes to see it on screen (barely
sub-second).

I do set the args.Handled = true event after I dealt with the key stroke.

thanks

Phil

PS Looking at the performance logs and other WPF tool doesn't seem to
yield a lot of good information for my xbap application.

Hello Philippe,

> My application's responsiveness is getting really bad when the user
> modifies a text box. There is a big noticable delay between the time I
> enter a character and the time the control gets the focus back (and
> displays the character).
>
> Since a large team of individuals have been working on this project,
> it's hard for me to pinpoint what went wrong. Is there a place
> somewhere that I can use that would tell me where the code is between
> the key-press event and the time it takes to see it on screen (barely
> sub-second).
>
> I do set the args.Handled = true event after I dealt with the key
> stroke.
>
> thanks
>
> Phil
>
> PS Looking at the performance logs and other WPF tool doesn't seem to
> yield a lot of good information for my xbap application.
>

We ran into problem with shadows on a popup we had. Once we removed the drop
shadow affect the type-delay issue went away. Hope that helps.

-Paul

Paul Czywczynski wrote:
> Hello Philippe,
>
>> My application's responsiveness is getting really bad when the user
>> modifies a text box. There is a big noticable delay between the time I
>> enter a character and the time the control gets the focus back (and
>> displays the character).
>>
>> Since a large team of individuals have been working on this project,
>> it's hard for me to pinpoint what went wrong. Is there a place
>> somewhere that I can use that would tell me where the code is between
>> the key-press event and the time it takes to see it on screen (barely
>> sub-second).
>>
>> I do set the args.Handled = true event after I dealt with the key
>> stroke.
>>
>> thanks
>>
>> Phil
>>
>> PS Looking at the performance logs and other WPF tool doesn't seem to
>> yield a lot of good information for my xbap application.
>>
>
> We ran into problem with shadows on a popup we had. Once we removed the
> drop shadow affect the type-delay issue went away. Hope that helps.
>
> -Paul
>

I tried to remove all the shadows on my project. But it didn't help.
Thanks for the suggestion though.

It's kind of weird that a drop shadow would do this on a final release
of WPF though.

Phil

Hello Philippe,

> Paul Czywczynski wrote:
>
>> Hello Philippe,
>>
>>> My application's responsiveness is getting really bad when the user
>>> modifies a text box. There is a big noticable delay between the time
>>> I enter a character and the time the control gets the focus back
>>> (and displays the character).
>>>
>>> Since a large team of individuals have been working on this project,
>>> it's hard for me to pinpoint what went wrong. Is there a place
>>> somewhere that I can use that would tell me where the code is
>>> between the key-press event and the time it takes to see it on
>>> screen (barely sub-second).
>>>
>>> I do set the args.Handled = true event after I dealt with the key
>>> stroke.
>>>
>>> thanks
>>>
>>> Phil
>>>
>>> PS Looking at the performance logs and other WPF tool doesn't seem
>>> to yield a lot of good information for my xbap application.
>>>
>> We ran into problem with shadows on a popup we had. Once we removed
>> the drop shadow affect the type-delay issue went away. Hope that
>> helps.
>>
>> -Paul
>>
> I tried to remove all the shadows on my project. But it didn't help.
> Thanks for the suggestion though.
>
> It's kind of weird that a drop shadow would do this on a final release
> of WPF though.
>
> Phil
>

We've also had problems with bitmap effects. We had to remove an outerglow
because of the same problem. This occured in RC2 and the RTM.

<Border.BitmapEffect><OuterGlowBitmapEffect /></Border.BitmapEffect>

-Paul

The problem is that when you apply a bitmap effect to a Visual, WPF
responds by converting that visual to a bitmap, applying the effect and
then rendering it. This bypasses most of the acceleration pipeline and
as a result, it must rely on software rendering for the whole process.
Bottom line is that bitmap effects on visuals force software rendering
and that will directly impact performance if you use a lot of them.

Mark Smith

Philippe,

I agree that bitmap effects definitely slow down response time.

But also, I've found that running an application with a debugger attached
also slows down the user interface. For instance, in our WPF Wizard dialog
control, we have animated transitions between pages. If you run our sample
in debug mode via Visual Studio, the transitions are definitely not
"smooth". However if you run the application directly from Windows
Explorer, everything runs must better. I've seen this with other aspects of
the WPF UI as well. So if you are seeing a lag, make sure you try your app
outside of the debugger as well to see if that helps since that is what the
end user will see.

--

Bill Henning
Actipro Software

WPF Wizard Control -
http://www.actiprosoftware.com/Produ...d/Default.aspx



"Mark Smith" <mark.julmar@gmail.com> wrote in message
news:1169034668.485798.265710@s34g2000cwa.googlegroups.com...
> The problem is that when you apply a bitmap effect to a Visual, WPF
> responds by converting that visual to a bitmap, applying the effect and
> then rendering it. This bypasses most of the acceleration pipeline and
> as a result, it must rely on software rendering for the whole process.
> Bottom line is that bitmap effects on visuals force software rendering
> and that will directly impact performance if you use a lot of them.
>
> Mark Smith
>