This is possible but I'm not sure it'll achieve the effect that you are
after. If I understand you correctly, you'd like to show only one
frame (i.e. tell teh viewer that frame count is 1) retrieve it, then
tell the viewer that count is 2 and add that frame, then tell the
viewer count is 3, etc. The result will be an animated display in
debug view which will be odd and CPU intensive.
Another option is to assume that the frame count is the same as
previous frame count (caches from last suspend) and show those stack
frames as dummies until you recalculate them, then replace them one by
one as you calculate then in the service. The problem is that if you
have many more stack frames than what was in the previous stack trace,
you'll still end up with the animation effect.
You could achieve either effect by either extending the view model
implementation or by adjusting the service behavior. Changing the VM
is preferable because it won't affect ther service for other clients,
but it's also more complicated. The main problem is that the cache
implementation in the VM is separate from the VM nodes. To do
something sophisticated like this, you'll likely need to extend the
cache and open its API a bit. A complete redesign of the cache to
integrate it more tightly with VMCs is another option. It's more risky
but may simplify the VM logic in the long run.
Finally, you could just rely on the get more stack frames feature
that's currently in place and cap the default number of frames
retrieved at a small number (like 3). Then have the user double-click
to get more frames.
Cheers,
Pawel
On 04/28/2010 09:52 AM, ken.ryall@xxxxxxxxx wrote:
Re: [cdt-dev] Displaying DSF stack frames
OK, I’ve taken a closer look at how it works
now and that certainly makes sense.
I would like the behavior on suspend to be:
1 - Show the context suspended and display the top frame
2 - Ask the stack service to calculate the additional frames
3 - Insert the new frames as they become available
Cancel 2 & 3 if the context is resumed.
But I’m not sure what it would take in the view model to make this
happen.
Thanks - Ken
From: ext Pawel Piech
<pawel.piech@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wed, 28 Apr 2010 18:39:12 +0200
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Displaying DSF stack frames
Hi,
IStack.getTopFrame() and the delayed refresh logic in StackFramesVMNode
is primarily intended at optimizing stepping speed. When stepping, the
full refresh of the stack frames is delayed by 200ms and if in that
time a new step is executed, then the refresh is canceled. However,
this mechanism relies on the stack service for caching some stack
information while the target is stepping stepping so it's not ideal.
Specifically, as you pointed out the stack depth is retrieved from the
service to calculate the select delta for the top stack frame. I think
we could avoid this call if we were to enhance the view model cache a
little bit. I recently filed a bug for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=310518.
Cheers,
Pawel
On 04/28/2010 06:10 AM, ken.ryall@xxxxxxxxx wrote:
Displaying DSF stack frames Pawel,
I’m working on optimizing bits of the EDC debugger and have run across
an issue with displaying stack frames. In some circumstances when we’re
building the list of stack frames determining the next frame can become
an lengthy operation. This would be seem to be what IStack.getTopFrame
is designed to do, just return the first one to give the user immediate
feedback when a context is suspended, then bring in the remainder of
the frames later. But IStack.getStackDepth is also called, which I
understand is supposed to always return the complete number of frames,
which will bring on some of the lengthy work I’m trying to defer.
So I must be misunderstanding how this works, I’m looking into it but I
thought I would see if you had any advice.
Thanks - Ken
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
