Re: Many changes in layers and markers



On Sun, Feb 13, 2011 at 08:18, Robert Park <rbpark exolucere ca> wrote:
> On Sat, Feb 12, 2011 at 11:59 PM, Russell Strong <russell strong id au> wrote:
>> Yeah, I think you have followed it.  The basic idea is that all drawing,
>> sorting, and other expensive operations should be delayed until
>> main_interation, so that they can be done once instead of every time the
>> scenegraphs updated.  I haven't looked to closely but I think clutter
>> has to take some of the blame for things like sorting.
>
> Yeah, clutter is part of it, but Jiri's already created the
> ChamplainGroup that avoids the sorting performed in ClutterGroup and
> it's _still_ awfully slow. Cutting out the sorting sped up my
> benchmark file from 22 minutes to 12 minutes, still a long ways away
> from the 6s of the old API.
>
>> My flows just showed the event ending and getting retriggered instead of
>> your yielding approach, but essentially they are the same.
>
> Cool, so I did understand.
>

As I said in the other email, this should be fixed now. For those
interested, this is how it's implemented now. Instead of calling the
redraw_path() method directly after adding/removing nodes, I call
schedule_redraw(), which is implemented as follows:

static void
schedule_redraw (ChamplainPathLayer *layer)
{
  if (!layer->priv->redraw_scheduled)
    {
      layer->priv->redraw_scheduled = TRUE;
      g_idle_add_full (G_PRIORITY_DEFAULT_IDLE,
          (GSourceFunc) redraw_path,
          g_object_ref (layer),
          (GDestroyNotify) g_object_unref);
    }
}

The redraw is postponed to idle. Notice the redraw_scheduled flag - it
is set after the first point is added so only a single idle redraw is
performed for multiple node additions. The flag is then set back to
FALSE in the redraw_path() method.

Jiri


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]