Comments on our presentation

We got a lot of questions and positiv feedback on our presentation and we are very thankful for that. There were also two persons who pointed out, what they believed was, mistakes/errors in our presentation. This post is about those errors.

First of all one person told us that when we draw our component in the paintComponent() method we must consider the space that the border will use. If the border uses five pixels on the edges then we cannot paint anything on those 5 pixels. Yes that’s understood and maybe we should have said it but our goal is to make the code, in the presentation, easy to understand and that’s why we didn’t include it.

Secondly someone told us that when we change the location of the component in the Kinetic Scrolling code we shouldn’t do it directly but instead do it later, probably by using SwingUtilities.invokeLater(). The reason was that every time we changed the location of the component events will be fired and the source of those events will be our KineticScrolling component. I don’t understand what’s wrong with that? I believe that the KineticScrolling component should be what caused the event and nothing else, At least as long as we are running on the EDT. I’m going to investigate this further and let you know what the right way is.

8 Responses to “Comments on our presentation”


  1. 1 Freddy Guime

    Do you have the source code? I’m trying to go over the presentation and figure out where would the EDT violation be. I remember I saw it but now I can’t pinpoint it.

    Thanks!

    Freddy

  2. 2 Pär

    Hi, Freddy and thanks you for helping us out with our potential EDT violation. Below is the code that I think is the cause for your worries:


    @Override
    public void mouseDragged(MouseEvent e) {
        int diff = e.getYOnScreen() - previousMouseEvent.getYOnScreen();
        int newYPosition = componentToScroll.getY() + diff;
        componentToScroll.setLocation(0, newYPosition);
        previousMouseEvent = e;
        repaint();
    }

    setLocation method must be invoked on the EDT but since the mouseDragged method is invoked from the Event Dispatcher Thread there is no real problem. Am I right or can you see something that I have missed?
    I made sure that we’re really running on the EDT by printing the result from SwingUtilities.isEventDispatcherThread()

    Looking foreward to hear from you

  3. 3 Freddy Guime

    Ah, I see. I don’t think is on this part of the code, but instead is on the timingEvent (float progress), as the timing occurs outside of the EDT (or seems like it).

    There you call componentToScroll.setLocation, and I think the timing callbacks are done outside of the EDT.

  4. 4 Pär Sikö

    It turns out that we are both right :-) as the EDT problem depends on which timer implementation we use. The default one that the TimingFramework uses is javax.swing.Timer, and since this timer is designed to be used in Swing it always operate on the EDT so as long as you stick to this everything is fine and the application is not violating the EDT rule.
    Now if you take a look at the slides, specifically on page 36 – “Timing issues continued”, you will see that we implement our own TimingTarget and that’s where the problem starts. Our TimingTarget is very simple and depends on Thread.sleep(), instead of javax.swing.Timer, and this method is NOT executed on the EDT and that means that the timingEvent(float progress) is running outside of the EDT. See code below.


    @Override
    public void timingEvent(float progress) {
        int newY = (int) (startPosition + distanceToScroll * progress);
        componentToScroll.setLocation(0, newY);
        repaint();
    }

    Code 1. This is the code that is called by the TimingFramework every time the animations is to be updated. This is ok as long as the method is invoked from the EDT.


    public void start() {
      new Thread() {
        public void run() {
          while (!stop) {
            try {
              sleep(resolution);
            } catch (Exception e) { }
            timingEvent();
          }
        }
      }.start();
    }

    Code 2. This is our original (faulty) implementation. The problem is that we force all classes using this TimingSource to handle the EDT rule themself.
    I will post a new version of our TimingTarget very soon

  5. 5 Daan

    Hi, we are currently building an application in which kenetic scrolling would be an enormous usabilty feature. Can you give us an indication when you will release the source code of your kenetic scrolling implementation?

  6. 6 Pär

    This is a little bit embarassing because the entire Feedjii project should have been open sources a long time ago. The first time we said that we were gonna do it was back in the beginning of the year, then we got accepted to speak at JavaOne and we focus on that but now there is no conference or other activity to blaim so I guess we just have to do it :-)
    I will add a post within a week with links to source code and documentation for the kinetic scrolling component. I promise…… eh ….. yes I promise ;-)

    Maybe we should add the project to Kenai?

  7. 7 Håkan Lidén

    Hi
    In an article att it24 (http://it24.idg.se/2.2275/1.232661/svensk-duo-ska-lara-ut-design-till-javavarlden) you mention a book by two developers from sun. I would very much like to by it, but don’t know where to start looking. :) Can you help me?

  8. 8 Pär Sikö

    The book you’re looking for is “Filthy Rich Clients” by Chet Haase and Romain Guy. It’s a really good book, easy to read and best of all it’s NOT a 1000-pages book ;-)

Leave a Reply