Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Adding extra features

Developers
2008-06-17
2013-05-15
  • Hi,

    I'm working in the SW department of Philips Brugge.  We use TimeDoctor extensively to visualize task switch traces on our Linux system.  There are some extra features we'd like to add, and possibly merge them in the open source archive if you agree.

    Here's our list with ideas (doc with more details + drawings sent to Ruud and Mahesh via private mail):

    * Possibility to add "bookmarks" in the trace, e.g. by ctrl-clicking in the graphical trace view.

    * Organize tasks in a hierarchical structure, based on the Linux parent/child and threadgroup/thread relations. The tdi format would probably need to be extended with extra tags to represent this information.

    * Sub-pixel cpu load visualization. When zoomed out, the task scheduling bar gets colored black when task switches occur below the display resolution.  To still have an idea of a tasks cpu load in such case, we like visualize the load differently, e.g. by using gray scales or by changing the height of the bar.

    * Mixed tasks/agents view. We typically use agents to show activities run by tasks.  For us, it would therefore be useful to have a combined view on the task scheduling and the agent activity the task is running.  Task switches could e.g. be drawn on a colored background representing the agent activity.

    * Show notes on the task bar itself. Again for our use case, notes are always associated to a specific task so it would be very practical to show the note flags in the task view.

    Development can be taken up here.  We would of course prefer to get the changes in the open source archive too. So how do you like our ideas? Do you consider them useful for the rest of the TimeDoctor community? Who can we contact for technical advice, rules to be followed, design etc.?

    Kind regards,
    Pieter

     
    • Mahesh DC
      Mahesh DC
      2008-06-19

      Hi Pieter,

      > * Possibility to add "bookmarks" in the trace, e.g. by ctrl-clicking in the graphical trace view.

      This feature already exists via "Markers". When a user double-clicks on any line, a vertical "grey" colored line is set. A slightly different feature implementation is still pending (Annotation (add comment) to samples). Please see https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=130324&group_id=174793&group_project_id=48797

      > * Organize tasks in a hierarchical structure, based on the Linux parent/child and threadgroup/thread relations. The tdi format would probably need to be extended with extra tags to represent this information.

      A very nice feature, however, I am not very sure about the SWT (the backbone of Eclipse) support for this. We can still give it a try.
      Nevertheless, we have to ensure the backward compatibility, while extending TDI.

      > * Sub-pixel cpu load visualization. When zoomed out, the task scheduling bar gets colored black when task switches occur below the display resolution. To still have an idea of a tasks cpu load in such case, we like visualize the load differently, e.g. by using gray scales or by changing the height of the bar.

      Sounds Cool!

      > * Mixed tasks/agents view. We typically use agents to show activities run by tasks. For us, it would therefore be useful to have a combined view on the task scheduling and the agent activity the task is running. Task switches could e.g. be drawn on a colored background representing the agent activity.

      While doing this, we will have to ensure that, the existing visualization is also supported for other users, maybe via a check-box in the preference page.

      > * Show notes on the task bar itself. Again for our use case, notes are always associated to a specific task so it would be very practical to show the note flags in the task view.
      Alternatively, can the notes become part of the tool-tip (popup) for the task. So, when the user hovers the mouse over the task, the notes associated in that range (idle, running, stopped) are displayed.

      > Development can be taken up here. We would of course prefer to get the changes in the open source archive too. So how do you like our ideas? Do you consider them useful for the rest of the TimeDoctor community? Who can we contact for technical advice, rules to be followed, design etc.?

      For technical discussions, design etc., please post it to this forum.
      For sending the code, I suggest to raise a Feature request via https://sourceforge.net/tracker/?func=add&group_id=174793&atid=870649 first and also attach the patch to it for analysis. That way, we can ensure tracking each feature seperately.

      Thanks & Regards,
      Mahesh

       
    • Hi Mahesh,

      Thanks for your support.  I tried the markers feature on the latest version and it seems to work fine, so no need to change anything there.

      For the others, we first need some time to study the sources and the possibilities, and let you know as soon as we have something.  We'll certainly take into account your concern for backwards compatibility.

      Kind regards,
      Pieter

       
    • Hi all,

      I've been busy with Time Doctor for about an week now, and the first extra feature has been implemented: the sub-pixel load visualization. I've posted a patch at the Feature request page.

      I still have some problems. I'm busy with the preference page (I've added a check box for the SubPixelLoad feature), but TimeDoctor does not redraw the traces automatically when changing the check box. Can someone give me a suggestion about how I should implement this?

      I'm also trying to build the RCP application, but the builder complains that not all plugins are found. Could someone who had already built it tell me where you can download all the plugins/features needed for building TimeDoctor? Now I have copied the entire plugin/feature folder of eclipse 3.3.2 and the RCP pack (eclipse-RCP-3.3.1.1-delta-pack) into sources/.

      Are there some configurationfiles that you need to change? (I've changed only the path to eclipse.exe in masterbuild.cmd)

      Kind regards,

      Willem

       
    • Hello,

      I've managed to build the RCP application at home with Eclipse 3.3.1.1. At work I have 3.4.
      When I have some time left I will see why it isn't building with Eclipse 3.4.

      I also want to mention that the patch i made in Eclipse 3.4 doesn't work with Eclipse 3.3.1.1. I will also investigate that later when I have some time left.

      Kind regards,

      Willem

       
      • Mahesh DC
        Mahesh DC
        2008-07-07

        Hi Willem,

        > I've been busy with Time Doctor for about an week now, and the first extra feature has been implemented: the sub-pixel load visualization. I've posted a patch at the Feature request page.
        I have taken a brief look into it. I have added some comments and made some changes. I have re-attached it as a patch into the feature. Please take a look.

        > I still have some problems. I'm busy with the preference page (I've added a check box for the SubPixelLoad feature), but TimeDoctor does not redraw the traces automatically when changing the check box. Can someone give me a suggestion about how I should implement this?
        Take a look in QueueCanvas.java and QueuePaintListener.java for ideas. The idea is that, you listen for preference changes in your TaskCanvas (you can see that propertyChange() method in TaskCanvas is currently empty). In the propertyChange() implement your logic and then call redraw(). This will result into a call to the TaskPaintListener's paintControl() method.

        About RCP build, I suggest you stick to 3.3.2 (or 3.3.1.1) for the moment. Once things are stable, let's try with 3.4.
        For your own debug, you should be using workbench.product in com.nxp.timedoctor.feature.workbench feature project. If I am misunderstanding, please let know the exact problems that you are facing.

        -Mahesh

         
    • Hi Mahesh,

      >> I still have some problems. I'm busy with the preference page (I've added a check box for the SubPixelLoad feature), but TimeDoctor does not redraw the traces automatically when changing the check box. Can someone give me a suggestion about how I should implement this? 
      >Take a look in QueueCanvas.java and QueuePaintListener.java for ideas. The idea is that, you listen for preference changes in your TaskCanvas (you can see that propertyChange() method in TaskCanvas is currently empty). In the propertyChange() implement your logic and then call redraw(). This will result into a call to the TaskPaintListener's >paintControl() method.

      I've made some changes, but I don't see how I can (simple) change the setSubpixel for every listener in the propertyChange() function. The redrawing works now, but the changing of the subpixel boolean is still done in the listener
      I will post a v5 of the patch (with the preference page and an improved draw algorithm), please take a look.

      >About RCP build, I suggest you stick to 3.3.2 (or 3.3.1.1) for the moment. Once things are stable, let's try with 3.4.
      For your own debug, you should be using workbench.product in com.nxp.timedoctor.feature.workbench feature project. If I am misunderstanding, please let know the exact problems that you are facing.

      Building works with 3.3.1.1. I have made a small guide for building, i will mail it to you Mahesh.

      Kind regards,

      Willem

       
    • Hi all,

      I've posted a patch for the combined view. Please have a look.

      I will give you some more information about it.

      I've added a new tag for the .tdi file. The syntax:
      COM <id> <line_type> <line_id>
      One can give the id of the new Combination line (in the code often shortened to Combo), and add an existing line (every kind of line is possible), or one can add an existing line to the Combination line with given ID.

      When loading older files in the new TimeDoctor, one will not experience problems (just like you load a file without e.g. queues - the queue section is not displayed).
      Loading new filed in an older TimeDoctor will just give a warning (because the parser does not recognize the COM commands). All the other tracelines will be rendered correctly.

      I've overloaded 'Sample', so it can holds the extra information. Every sample in a combination line represents another line (by its type en ID).

      When displaying a combination line, a tree will be build. Because it is impossible to set if a TreeItem is visible or invisible, the tree needs to be rebuild every time the hide/auto-hide option is changed - a combination line is set invisible - the combination section expands/collapses.
      I save the trace and separator in a hashMap, so i can set them visible/invisible when the tree expands/collapses.
      It is also impossible to set the height of the treeItems. I've found a workaround, but it's not possible to set the height of the items in a tree separately. So resizing of the traces is not possible in the combined view.

      Displaying the children of the tree is done by adding a paintlistener for this line(just like for normal tasks/agents/...). For the root item all the paintlisteners (of the children) are added. The first line will be drawn first (this is a special line, it draws also the background, and you can set it's height in the preference page), and then the second on top of it, followed by the third and so on. These lines does not draw the background, otherwise the traces beneath this trace wouldn't be visible.
      For this I had to change all the paintListeners.

      As mentioned before I've added an extra option in the preference page. From our own experience here sometimes the 'sum trace' is more visible when the first trace occupies the full height, and sometimes it is better visible when the height is e.g. half of the full height.

      I've also added two new buttons in the actionbar (and the menu). With this button one can expand/collapse all the combination lines. Apparently the icons are not displayed in the RCP version...

      If you have some more questions, don't hesitate to ask them!

      Kind regards,

      Willem

       
      • Mahesh DC
        Mahesh DC
        2008-07-30

        Hi Willem,

        I would like to close the "sub-pixel cpu load visualization" feature, before looking into this.
        I will let you know, if I have any comments on the v6 patch.

        -Mahesh

         
        • Hi,

          From a user perspective, I tested both the sub-pixel view and the combined view and it looks absolutely fine.  It's really what I expected from it.  Good work!

          Regards,
          Pieter

           
      • Mahesh DC
        Mahesh DC
        2008-08-05

        Hi Willem,

        Please see my comments inline ...

        >> I've added a new tag for the .tdi file. The syntax:
        >>  COM <id> <line_type> <line_id>
        >> One can give the id of the new Combination line (in the code often shortened to Combo), and add an existing line (every kind of line is possible), or one can add an existing line to the Combination line with given ID.

        Does it mean more than two lines can be part of a combination ? Examples could be Task1 <---> Queue <---> Task2 or Task <---> ISR <---> Agent

        >> When displaying a combination line, a tree will be build. Because it is impossible to set if a TreeItem is visible or invisible, the tree needs to be rebuild every time the hide/auto-hide option is changed - a combination line is set invisible - the combination section expands/collapses.
        >> I save the trace and separator in a hashMap, so i can set them visible/invisible when the tree expands/collapses.
        >> It is also impossible to set the height of the treeItems. I've found a workaround, but it's not possible to set the height of the items in a tree separately. So resizing of the traces is not possible in the combined view.

        Inability to resize is a pity. It could be an 'accessibility' issue, when combined with sub-pixel load visualization or when queues are being displayed proportionally. Although, the preference page option seems to solve it to an extent, for a user, it will be difficult to predict the correct setting in the slider and often, they may have to change the slider setting again and again when viewing different lines.

        Did you try the first method suggested in the feature request:  https://sourceforge.net/tracker/index.php?func=detail&aid=2004144&group_id=174793&atid=870649
        ie., display the combined lines next to each other. We can probably also add extra spacing between each combinations to visually seperate each combination.

        Another issue with the current visualization is that, it will be difficult or even impossible to render tooltips for the combined traceline. Currently, it is not done at all.

        >> As mentioned before I've added an extra option in the preference page. From our own experience here sometimes the 'sum trace' is more visible when the first trace occupies the full height, and sometimes it is better visible when the height is e.g. half of the full height.

        Regards,
        Mahesh

         
        • Please see my comments inline ...

          >>>> I've added a new tag for the .tdi file. The syntax: 
          >>>> COM <id> <line_type> <line_id> 
          >>>> One can give the id of the new Combination line (in the code often shortened to Combo), and add an existing line (every kind of line is possible), or one can add an existing line to the Combination line with given ID. 
          >>
          >>Does it mean more than two lines can be part of a combination ? Examples could be Task1 <---> Queue <---> Task2 or Task <---> ISR <---> Agent

          Yes, one can add as many lines as wanted. Also adding two times the same line is possible

          >>>> When displaying a combination line, a tree will be build. Because it is impossible to set if a TreeItem is visible or invisible, the tree needs to be rebuild every time the hide/auto-hide option is changed - a combination line is set invisible - the combination section expands/collapses. 
          >>>> I save the trace and separator in a hashMap, so i can set them visible/invisible when the tree expands/collapses. 
          >>>> It is also impossible to set the height of the treeItems. I've found a workaround, but it's not possible to set the height of the items in a tree separately. So resizing of the traces is not possible in the combined view. 

          >>Inability to resize is a pity. It could be an 'accessibility' issue, when combined with sub-pixel load visualization or when queues are being displayed proportionally. Although, the preference page option seems to solve it to an extent, for a user, it will be difficult to predict the correct setting in the slider and often, they may have to change the slider setting again and again when viewing different lines.

          I haven't taken the proportional queues in account, but that will indeed give some issues i think.
          I don't understand the problem with the slider. With the slider one can change the padding of the first trace, not the entire height of the traceCanvas, or am I understanding you wrong?

          >>Did you try the first method suggested in the feature request: https://sourceforge.net/tracker/index.php?func=detail&aid=2004144&group_id=174793&atid=870649
          >>ie., display the combined lines next to each other. We can probably also add extra spacing between each combination's to visually separate each combination. 
          When the tree is expanded, one can see all the traces side by side (first method). The root item contains the second method (everything on top of each other)

          It's indeed a possibility to set the padding between the traces smaller (or even 0). Adding some extra spacing is also easily done. If you want i can implement this, but I think the visibility is now good enough. Placing the traces closer to each other will make the view more complex I think.

          >>Another issue with the current visualization is that, it will be difficult or even impossible to render tooltips for the combined traceline. Currently, it is not done at all.

          Yes that's true. But the question is if it's needed for a combination view. If you display e.g. 5 traces on top of each other, which tooltip you have to show? A possibility is to show the toolip of all the traces together (I don't think that is very difficult to do)

          >>>> As mentioned before I've added an extra option in the preference page. From our own experience here sometimes the 'sum trace' is more visible when the first trace occupies the full height, and sometimes it is better visible when the height is e.g. half of the full height. 

          Regards,

          Willem

           
    • I've added the third and last feature. Please review it.

      Kind regards,

      Willem