Problem with positioning of event tape (and label)

13 views
Skip to first unread message

M. Donovan

unread,
Jul 31, 2008, 5:17:39 PM7/31/08
to SIMILE Widgets
I have a timeline that is displaying two events. One event runs from
7/16 - 7/31; the other event occurs on 7/18 (only 20 minutes long).
The lower band of the timeline shows about 4 days at a time and when
the timeline initially loads, the event runnning from 7/16 - 7/31 is
displayed at the very top of the timeline (track 0 I assume).

As I drag the timeline in order to get to the other event on 7/18, the
first event stays on track 0. Once I get "close" to the event on
7/18, the first event now jumps down to track 1 and the 7/18 event is
on track 0. If I continue to drag to older dates, eventually the
first event jumps back up to track 0.

Is there anything I can do to prevent this "track jumping" from
occurring? Is is picking track 0 for the first event because it
hasn't "processed" the 7/18 event yet? We were using a very old
version (r5442) and recently upgraded to r9147 - this "track jumping"
did not seem to happen in the older version we were using.

Any help would be greatly appreciated.

Thanks,
Mark

M. Donovan

unread,
Aug 6, 2008, 5:29:30 PM8/6/08
to SIMILE Widgets
Just thought I would bump this up so it doesn't get lost among all of
the spam posts.
I am still trying to figure out what is going on - any help would be
greatly appreciated.

Thanks,
Mark

David Huynh

unread,
Aug 7, 2008, 7:10:44 PM8/7/08
to simile-...@googlegroups.com
M. Donovan wrote:
> Just thought I would bump this up so it doesn't get lost among all of
> the spam posts.
> I am still trying to figure out what is going on - any help would be
> greatly appreciated.
>
This track jumping behavior is due to the event painter re-laying out
the events. In older code (that still has the shared "layout" concept),
the painter goes through all events and decides in one shot which track
each event is on. In newer code, the painter only considers the events
that fall into the visible window (plus some extra left and right
paddings). As you scroll the band, when new events must be rendered, the
painter re-decides what event goes where. This causes the track jumping
behavior.

This problem needs to be fixed in the event painter's code, but it's not
a trivial fix. In the newer code, the event painter tries to measure how
long each event label takes (how many pixels) so that the labels don't
get cropped or wrapped. That's a slow process, as it needs to "render"
the event label in an invisible place and then retrieving the
rendering's width. Doing this for only a small number of events is OK,
but doing it for all events in one shot at the beginning will cause the
timeline to "hang" upon loading. It's not immediately obvious to me how
to fix the track jumping problem while still avoid cropping/wrapping
event labels.

David

M. Donovan

unread,
Aug 8, 2008, 4:36:32 PM8/8/08
to SIMILE Widgets
Thanks for the response David. It sounds like this track jumping
behavior is something we may have to live with.
Reply all
Reply to author
Forward
0 new messages