Problems re-rendering multi-series plot

4 views
Skip to first unread message

Sean O'Brien

unread,
Feb 19, 2010, 4:51:53 PM2/19/10
to protovis
I'm currently hacking on the minnesota employment vis. My goal has
been to have the mouse over dot rendered on all the plots, in doing
this I had some weird rendering problems that seemed related to
returning vis from the mouse event functions. To reproduce it more
simply, I took the code as provided and called vis.render(); twice
after all the code to setup the plots. It looks like all the graphs
get rendered in place of the last graph. Is there a reason why this
happens?

Thanks
-Sean

Mike Bostock

unread,
Feb 19, 2010, 5:09:32 PM2/19/10
to prot...@googlegroups.com
> It looks like all the graphs get rendered in place of the last graph.
> Is there a reason why this happens?

Yes, I suspect this is a known bug that occurs when you have a root
panel with multiple data elements. (In this case, multiple SVG
elements are generated.) I've implemented a fix for the next version
(3.2) in development. You can try a pre-release version if you don't
mind building it yourself: http://gitorious.com/protovis

Mike

Sean O'Brien

unread,
Feb 19, 2010, 5:28:28 PM2/19/10
to prot...@googlegroups.com
I downloaded the master tarball, ran make and used the r3.2.js that
was generated and it looks like events are broken in the current
build. Is there anything special I need to do aside from running make
on it?


-Sean

> --
> You received this message because you are subscribed to the Google Groups "protovis" group.
> To post to this group, send email to prot...@googlegroups.com.
> To unsubscribe from this group, send email to protovis+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/protovis?hl=en.
>
>

Mike Bostock

unread,
Feb 19, 2010, 5:36:56 PM2/19/10
to prot...@googlegroups.com
> I downloaded the master tarball, ran make and used the r3.2.js that
> was generated and it looks like events are broken in the current
> build.

Events aren't broken in 3.2, but there are other changes afoot that
may affect you.

Without being able to look at your example or the error messages in
more detail, I won't be able to say what the cause is. If you can,
send a link or attach a test case (or your example). Otherwise, use
the -d3.2js and tell me what the error message and stack trace are.

Thanks,
Mike

Sean O'Brien

unread,
Feb 19, 2010, 6:22:14 PM2/19/10
to prot...@googlegroups.com
Ahh yes, looking at the console would be a good idea :). I attached
the source. For what it's worth I just copied the exact code from the
examples page and pointed it at the js I compiled. I get the
following exception...

(new Date(2000, panel.i() * 3, 1)).format is not a function

It comes from the .text call that fills the label below each plot.
Interestingly, if I remove that call, the dot works as expected, but
the currently moused over plot disappears(or maybe it's just turning
white instead of green). Changing the "#2ca02c" to pv.rgb(0, 125, 0)
in the Area's fillStyle fixes that.

Thanks,
-Sean

min.html

Mike Bostock

unread,
Feb 19, 2010, 6:41:47 PM2/19/10
to prot...@googlegroups.com
> (new Date(2000, panel.i() * 3, 1)).format is not a function

One of the improvements in 3.2 is to no longer extend from built-in
JavaScript classes. So Date.format and Date.parse have been replaced
with a pv.Format.date class. (There's another pv.Format.time, too, for
durations.) You can replace the code with:

pv.Format.date("%B %Y")(new Date(2000, panel.i() * 3, 1))

> Changing the "#2ca02c" to pv.rgb(0, 125, 0) in the Area's fillStyle fixes that.

Woot, you found a bug. In 3.2, properties have explicit types. So,
when the fillStyle property is evaluated, Protovis knows it is a
color, and so you can depend on it being a color (which is nice if you
want to compute derivative colors using brighter/darker/alpha).
However, this particular example is using a def to define the
fillStyle property. In this case, the computed value was not
automatically being converted to a pv.color, so you'll need to do it
by hand (e.g., pv.color("#2ca02c")). I'll fix this and make sure that
defs go through the appropriate type conversion on render.

Mike

Mike Bostock

unread,
Feb 19, 2010, 8:04:50 PM2/19/10
to prot...@googlegroups.com
>> Changing the "#2ca02c" to pv.rgb(0, 125, 0) in the Area's fillStyle fixes that.
>
> Woot, you found a bug.

This bug has now been fixed, if you grab the latest from Gitorious.

Cheers,
Mike

Sean O'Brien

unread,
Feb 19, 2010, 8:07:21 PM2/19/10
to prot...@googlegroups.com

Awesome, will do.  Also, me re-rendering problem is gone.

Thanks again,
-sean

On Feb 19, 2010 5:04 PM, "Mike Bostock" <mbos...@cs.stanford.edu> wrote:

>> Changing the "#2ca02c" to pv.rgb(0, 125, 0) in the Area's fillStyle fixes that.
>

> Woot, you fou...

This bug has now been fixed, if you grab the latest from Gitorious.

Cheers,

Mike

--
You received this message because you are subscribed to the Google Groups "protovis" group...

Pedro Alves

unread,
Feb 22, 2010, 8:37:26 AM2/22/10
to prot...@googlegroups.com, Mike Bostock

On 10/02/20 01:04, Mike Bostock wrote:
> This bug has now been fixed, if you grab the latest from Gitorious.


Is the latest code not in googlecode's svn anymore? I've seen lots of
activity in http://gitorious.org/protovis, but not announced. Is this
official?


-pedro

Mike Bostock

unread,
Feb 22, 2010, 2:56:41 PM2/22/10
to Pedro Alves, prot...@googlegroups.com
> Is the latest code not in googlecode's svn anymore? I've seen lots of
> activity in http://gitorious.org/protovis, but not announced. Is this
> official?

Yes. It has not been announced because we want to let the code "bake"
somewhat before we make an official release. There are still a number
of features under development. If you are interested in testing out a
pre-release version and giving feedback, please clone the repo or
download the tarball!

Mike

John Firebaugh

unread,
Feb 22, 2010, 3:33:02 PM2/22/10
to prot...@googlegroups.com
On Mon, Feb 22, 2010 at 11:56 AM, Mike Bostock <mbos...@cs.stanford.edu> wrote:
Yes. It has not been announced because we want to let the code "bake"
somewhat before we make an official release. There are still a number
of features under development. If you are interested in testing out a
pre-release version and giving feedback, please clone the repo or
download the tarball!

Mike,

I'm thrilled to see protovis moving toward a distributed VCS.

Any plans to rebase your tree onto the imported subversion history? It would be nice to preserve the history, and it would make it easier to merge the changes from my github fork.

Mike Bostock

unread,
Feb 22, 2010, 8:29:24 PM2/22/10
to prot...@googlegroups.com
> Any plans to rebase your tree onto the imported subversion history? It would
> be nice to preserve the history, and it would make it easier to merge the
> changes from my github fork.

After some hair-pulling, John and I have succeeded in importing the
full SVN history into Gitorious!

My apologies to those of you that already have a local clone of the
repo; you will need to recover from our upstream rebase. You can
either re-clone the repo, or follow John's instructions below.

Mike

-- begin git help --

If you didn't actually have any local commits beyond what's currently
pushed to origin/master, you can use the following command to reset:

git checkout master
git reset --hard origin/master

If you did have local commits, you can rebase them onto origin/master.
This is typically just:

git checkout master
git rebase origin/master

In this case git might get confused and try to merge identical
commits. If this happens, back out:

git rebase --abort

And then do an interactive rebase:

git rebase -i origin/master

Your editor will come up with a list of potential commits to be
rebased. For any duplicate commits already in origin/master, delete
those lines. Then save and exit the editor. Git rebase will run, but
skip the commits you deleted.

For more information, see the "RECOVERING FROM UPSTREAM REBASE" section here:

http://kernel.org/pub/software/scm/git/docs/git-rebase.html

Sean O'Brien

unread,
Feb 23, 2010, 5:46:54 PM2/23/10
to prot...@googlegroups.com
I have one last question around something I can't really wrap my head
around. Right now the code I have creates a bunch of panels,
essentially one per timeseries I want to plot. For each of those
panels, I add various things like an area, a dot, etc. Now if I
create a variable to hold one of those elements(dot), what does that
variable refer to. The prototype of the dot, all instances of the
dot, or both? Example:

var vis = new pv.Panel()
.data(minnesota)
.....
var panel = vis.add(pv.Panel)
.......
var dot = panel.add(pv.Dot) //What do I refer to?
......

I have code later in my vis that catches mouse events and calls
dot.render(). When I do that only the dot instance from the panel I
am currently mousing over seems to receive the render call. What
magic is happening to make the target of my dot.render() call always
change?

panel.add(pv.Bar)
.event("mouseout", function() {
panel.i(-1);
vis.i(-1);
dot.render();
label.render();})

min_expanded.html
protovis-d3.2.js

Mike Bostock

unread,
Feb 23, 2010, 6:16:24 PM2/23/10
to prot...@googlegroups.com
> var dot = panel.add(pv.Dot) // What do I refer to?

You have a Mark, which is a description of a set of related visual
elements. So the simple answer is that the `dot` refers to all
instances. Behind-the-scenes (no pun intended), this corresponds to a
hierarchical expansion from marks to visual items, also known as nodes
in the scene graph. The items are referenced in the `scene` property:

http://protovis-js.googlecode.com/svn/trunk/jsdoc/symbols/pv.Mark.html#scene

Consider the simple case of a lone Dot:

vis.add(pv.Dot)
...

If this dot were hypothetically rendered, since it lacks a data
property the default would be used, and a single Dot visual item would
be displayed. So after the render, dot.scene is a 1-element array. Now
consider a Dot with a data property:

vis.add(pv.Dot)
.data(pv.range(5))
...

When this dot is rendered, it's `scene` array would contain 5
elements, one per visual item. But what happens when both a Dot and
its parent Panel are multiplied?

vis.add(pv.Panel)
.data(pv.range(n))
.add(pv.Dot)
.data(pv.range(m))
...

We now have n*m dots. The hierarchy is stored on the panel's `scene`
attribute: panel.scene contains n elements. Each of those n elements
corresponds to a visual instantiation of the panel (along with the
panel's computed properties, like left and top). Each of those n
elements has a `children` attribute, which in this case is a 1-element
array since the panel only has one children. And those in turn
reference the dot's scene, an m-element array of the rendered Dots.

As marks are being rendered, Protovis internally sets and unsets the
`scene` attribute on each Mark so that it points to the correct place
in the hierarchy. The `index` property similar gets set to the current
instance. So in the above example, if we are rendering the ith panel,
then panel.index == i, and dot.scene == panel.scene[i].children[0].

> What magic is happening to make the target of my dot.render() call always
> change?

When event handlers are triggered, Protovis knows which instance of
the given mark (which visual item) triggered the event. It
correspondingly sets up the `scene` and `index` attributes for the
hierarchy before invoking the event handler. When render is called,
render checks to see if the `scene` and `index` attributes are set; if
they are, only those specific instances are rendered. Otherwise, if
render is called from a global context, Protovis will render all
instances of the given mark.

Mike

Reply all
Reply to author
Forward
0 new messages