EventViewer Rewrite

EventViewer Rewrite

[Sami Wagiaalla]

As some of you may know I have been working on a complete
rewrite of the EventViewer widget.

I have committed my changes to the NEW_EVENTVIEWER branch

to check it out:

    cvs  co -r NEW_EVENTVIEWER frysk

The new EventViewer is not ready to be merged yet but you can take
a look to see the general look and feel.

It is written completely in Java using java-cairo.
It has a sofisticated drawing hiarchy of composing objects to suppor
unlimmited fancyness :).

Events are independent of time lines. They are kept track of by EventManager
to support reuse of objects and on the fly redistribution, filtering, 
switching
between modes and whatever we may need in the future.

For example if the user wants to switch from having a time line per thread,
to having one per machine, or even a time line for all events of type X or
shared library Y, etc. This is made easier by EventManager.

Anyhow it should be up to speed and ready to be merged soon. I will aso need
Nurdin's help to put in Accessibility info :)

Happy hacking,

    Sami Wagiaalla

Re: EventViewer Rewrite

[Sami Wagiaalla]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

A couple of screen shots of how things look so far
both are of syscall observers, one added to firefox-bin,
and the other to a bunch of funit-child processes.

This model is timeless. One way time support could be added
is by adding an event loop 'tick' event to EventManager.

Events have an index, and as you can tell the events for a proc
is just the compilation of events of its threads.

Scrolling support is disabled as that is going to be part of the
histogram.

More to come:
- button for observers.
- button for blockers.
- maybe icon for status.
- Histogram of events.

Any thoughts/suggestions ?

[-- Attachment #2: snapshot8.png --]
[-- Type: image/png, Size: 29958 bytes --]

[-- Attachment #3: snapshot9.png --]
[-- Type: image/png, Size: 42385 bytes --]

Re: EventViewer Rewrite

[Sami Wagiaalla]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

My changes have been merged in and much more.

The attached screen-shot is of the funit-child process, which
I then signal to clone. In this session there are SyscallObserver,
SignalObserver, and CloneObserver.

Please give your comments, and suggestions about absolutly every
thing relating to our EventViewer widget (what we want from it, and
what it should look like).



[-- Attachment #2: ScreenShot1.png --]
[-- Type: image/png, Size: 43802 bytes --]

Re: EventViewer Rewrite

[Phil Muldoon]

Looks good! My only immediate comment would be to lose the border around 
the eventviewer. What does the X axis scale too? What does an event on 
the X axis belong to? Time?

Regards

Phil

Sami Wagiaalla wrote:
> My changes have been merged in and much more.
>
> The attached screen-shot is of the funit-child process, which
> I then signal to clone. In this session there are SyscallObserver,
> SignalObserver, and CloneObserver.
>
> Please give your comments, and suggestions about absolutly every
> thing relating to our EventViewer widget (what we want from it, and
> what it should look like).
>
>
>
> ------------------------------------------------------------------------
>

Re: EventViewer Rewrite

[Mike Cvet]

On Wed, 2007-01-10 at 13:34 -0600, Phil Muldoon wrote:
> Looks good! My only immediate comment would be to lose the border around 
> the eventviewer. What does the X axis scale too? What does an event on 
> the X axis belong to? Time?

Sami,

The new EventViewer stuff looks really impressive. Awesome work!

I'd have to second Phil's questions though - I think we need some
semblance of time, or relative time between events on the X axis.

Another question: Why do the second and third lines co-mingle? Why
doesn't 22441 have events occurring on a single line like 22437? Or is
that because the events on the third line have a different tag than the
events on the first and second lines?

- Mike

Re: EventViewer Rewrite

[Sami Wagiaalla]

> The new EventViewer stuff looks really impressive. Awesome work!
>   
Thanx :)
> I'd have to second Phil's questions though - I think we need some
> semblance of time, or relative time between events on the X axis.
>   
The model I am basing this on and the one we already know works is that
of printf debugging, were the user doesn't really care about time.

The design of the new EventViewer makes it really easy to add a time tick
(just another event). A reasonable suggestion made by Cagney when we
had this dicussion a while back was to add a time tick every time the event
loop loops.
> Another question: Why do the second and third lines co-mingle? Why
> doesn't 22441 have events occurring on a single line like 22437? Or is
> that because the events on the third line have a different tag than the
> events on the first and second lines?
>   
The first line is the process which is a cumilation of all the events 
occuring
within the process regardless of what thread they blong to.

the second line is the main thread of the process. Until a second thread is
spawned the main thread is identicall to the process. because all events
occure on the main thread.

The third line represents a second thread which is not spawned untill the
event that says "cloned by 22437" which is the thread id of the thread which
called clone.

does that make sense ^ ?

Re: EventViewer Rewrite

[Mike Cvet]

On Wed, 2007-01-10 at 14:56 -0500, Sami Wagiaalla wrote:
> > The new EventViewer stuff looks really impressive. Awesome work!
> >   
> Thanx :)
> > I'd have to second Phil's questions though - I think we need some
> > semblance of time, or relative time between events on the X axis.
> >   
> The model I am basing this on and the one we already know works is that
> of printf debugging, were the user doesn't really care about time.

Fair enough!

> 
> The design of the new EventViewer makes it really easy to add a time tick
> (just another event). A reasonable suggestion made by Cagney when we
> had this dicussion a while back was to add a time tick every time the event
> loop loops.
> > Another question: Why do the second and third lines co-mingle? Why
> > doesn't 22441 have events occurring on a single line like 22437? Or is
> > that because the events on the third line have a different tag than the
> > events on the first and second lines?
> >   
> The first line is the process which is a cumilation of all the events 
> occuring
> within the process regardless of what thread they blong to.
> 
> the second line is the main thread of the process. Until a second thread is
> spawned the main thread is identicall to the process. because all events
> occure on the main thread.
> 
> The third line represents a second thread which is not spawned untill the
> event that says "cloned by 22437" which is the thread id of the thread which
> called clone.
> 
> does that make sense ^ ?

Yes, that clears it up, thanks! =)

- Mike

Re: EventViewer Rewrite

[Phil Muldoon]

Sami Wagiaalla wrote:
>
>> I'd have to second Phil's questions though - I think we need some
>> semblance of time, or relative time between events on the X axis.
>>   
> The model I am basing this on and the one we already know works is that
> of printf debugging, were the user doesn't really care about time.

Give that particular model and ...
>
> The design of the new EventViewer makes it really easy to add a time tick
> (just another event). A reasonable suggestion made by Cagney when we
> had this dicussion a while back was to add a time tick every time the 
> event
> loop loops.

The above, there might be a case (at some point) to make the behavior of 
the widget scriptable. (ie time tick or not, just count, etc). 
Personally I can see the printf model working with the tag-sets (tags 
tied to lines of code in a program) but wonder how useful it would to 
know that my program forked in the event-viewer, but not what time it 
forked. The immediate solution to that problem would have a custom 
observer create a log-event and plot to event-viewer. This bring us 
nicely to log and event-viewer integration (ie click a log entry in the 
log view, have it highlighted in the eventviewer). Certainly food for 
thought, and something to think on, down the line.

Regards

Phil

Re: EventViewer Rewrite

[Sami Wagiaalla]

> The above, there might be a case (at some point) to make the behavior 
> of the widget scriptable. (ie time tick or not, just count, etc). 
> Personally I can see the printf model working with the tag-sets (tags 
> tied to lines of code in a program) but wonder how useful it would to 
> know that my program forked in the event-viewer, but not what time it 
> forked. The immediate solution to that problem would have a custom 
> observer create a log-event and plot to event-viewer. This bring us 
> nicely to log and event-viewer integration (ie click a log entry in 
> the log view, have it highlighted in the eventviewer). Certainly food 
> for thought, and something to think on, down the line.
Its a good idea, scripting in particular has not occurred to me. 
Providing more detailed information when the user selects a particular 
event is in the plan. The time stamp could be provided there.

Integrating log and event viewer will make the event viewer multi 
purpose, fulfilling our requirement for an off-line viewer int he future.

Re: EventViewer Rewrite

[Sami Wagiaalla]

> Looks good! My only immediate comment would be to lose the border 
> around the eventviewer.
Funny I was just thinking about how that could be done :)
> What does an event on the X axis belong to? Time?
An index.  Ie events are plotted evenly by the order in which they 
occured, or
were observed by frysk rather.

Re: EventViewer Rewrite

[Nurdin Premji]

Sami Wagiaalla wrote:
>
>> Looks good! My only immediate comment would be to lose the border 
>> around the eventviewer.
> Funny I was just thinking about how that could be done :)
What about putting it in a notebook and having it eclipse style so you 
can create multiple tabs for each process you want to watch, with the 
main list being on the left? (So the ones you really care about are 
cached but the ones that you don't can always be opened up whenever you 
need to.)

Re: EventViewer Rewrite

[Sami Wagiaalla]

> What about putting it in a notebook and having it eclipse style so you 
> can create multiple tabs for each process you want to watch, with the 
> main list being on the left?
I have actually been seriously thinking of removing that panel on the 
left because it is a little redundant.
> (So the ones you really care about are cached but the ones that you 
> don't can always be opened up whenever you need to.)
On one level the user can filter away processes they dont care about at 
all when setting up the session. But I do realize the need to "zoom in" 
on one particular process in the session. I dont think tabs are the best 
way to do so. We'll have to wait and see how noisy the display gets.

Re: EventViewer Rewrite

[Phil Muldoon]

Sami Wagiaalla wrote:
>
>> What about putting it in a notebook and having it eclipse style so 
>> you can create multiple tabs for each process you want to watch, with 
>> the main list being on the left?
> I have actually been seriously thinking of removing that panel on the 
> left because it is a little redundant.

I'd still want to see a whole session view, and be able to do the right 
click -> manual observer operations on processes and threads. For me, a 
tree is a more natural place to do that.

On that note, I'd make the suggestion that we stay from redesigning the 
whole monitor, just so we can focus on the event-viewer right now.

Regards

Phil

Re: EventViewer Rewrite

[Nurdin Premji]

Sami Wagiaalla wrote:
> My changes have been merged in and much more.
Colors. I'm not sure what they should be but just the ability to change 
the color (for example to distinguish between event types) would be 
useful. Make it user set able with a couple of default themes (Fruit 
Loop -- all the primary colors, True Blue -- everything blue like it is 
now.)

Re: EventViewer Rewrite

[Nickolay V. Shmyrev]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

В Срд, 10/01/2007 в 14:13 -0500, Sami Wagiaalla пишет:
> My changes have been merged in and much more.
> 
> The attached screen-shot is of the funit-child process, which
> I then signal to clone. In this session there are SyscallObserver,
> SignalObserver, and CloneObserver.
> 
> Please give your comments, and suggestions about absolutly every
> thing relating to our EventViewer widget (what we want from it, and
> what it should look like).
> 

Sorry, but do you rotate monitor when reading text connected to events?
For me it seems rather hard to scan the text.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: EventViewer Rewrite

[Sami Wagiaalla]

> Sorry, but do you rotate monitor when reading text connected to events?
> For me it seems rather hard to scan the text.
>   
lol, good point :). Here is the reasoning behind the slanted text:

I wanted an easy way for the user to be able to scan the events
in a sequential way. If the text is placed horizontally and stacked
it is hard to tell the order, if it is horosontal and spaced out it
forces the user to do a lot of scrolling to see more events and get
a "big picture", and if the text is completely vertical its impossible
to read.

I will look into reducing the slant as much as possible, but I am
wide open to suggestions on another solution.

Sami Wagiaalla

Re: EventViewer Rewrite

[Sami Wagiaalla]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

How does this one look ?

This is firefox-bin with a SyscallObserver. Events are more spaced
out so that the text can be less slanted.

[-- Attachment #2: ScreenShot2.png --]
[-- Type: image/png, Size: 45539 bytes --]