Scaling of gaphor to large canvases?

[John Pye]

Hi all

I was wondering if any studies had been done on the performance of
Gaphor with large canvases, eg containing perhaps 2000 elements (plus
interconnecting lines)?

Apparently these sorts of sizes are a problem with certain other
.net-based canvas implementations, so it would be good to know how we
stand with this implementation.

Models of this size are apparently not out of the question for large
process flow diagrams, although that sounds likely to be the upper limit.

Cheers
JP

[Arjan Molenaar]

Hi,

There is the gmeye application, located at http://gaphor.devjavu.com/browser/gmeye
(has to be converted to GIT repo still). It's able to draw a map
(Poland and The Netherlands currently) and highlight the cities.

I haven't seen a test with items and interconnecting lines though.
It's worth a try :)

Thanks for the suggestion,

Arjan

[John Pye]

Hi Arjan

Arjan Molenaar wrote:
> Hi,
>
> There is the gmeye application, located at http://gaphor.devjavu.com/browser/gmeye
> (has to be converted to GIT repo still). It's able to draw a map
> (Poland and The Netherlands currently) and highlight the cities.
>
> I haven't seen a test with items and interconnecting lines though.
> It's worth a try :)
>

I was figuring that your quadtree way of working out which bits of the
canvas need to be drawn/updated would be pretty efficient, but I wasn't
so sure if the constraint solver would be quite so scalable... I wonder
if the 'gmeye' app doesn't really stress your constraint solver, perhaps?

An interesting optimisation that is used by other scenegraph libraries
(eg Open Inventor) is level of detail (LOD) controls, which when a
canvas/scene is zoomed out, limits the detail which is drawn for certain
tiny little item on the screen... detail which would have been
indiscernable, in any case.

Cheers
JP

[Arjan Molenaar]

On 27 Aug 2009, at 16:30, John Pye wrote:

>
> Hi Arjan
>
> Arjan Molenaar wrote:
>> Hi,
>>
>> There is the gmeye application, located at http://gaphor.devjavu.com/browser/gmeye
>> (has to be converted to GIT repo still). It's able to draw a map
>> (Poland and The Netherlands currently) and highlight the cities.
>>
>> I haven't seen a test with items and interconnecting lines though.
>> It's worth a try :)
>>
>
> I was figuring that your quadtree way of working out which bits of the
> canvas need to be drawn/updated would be pretty efficient, but I
> wasn't
> so sure if the constraint solver would be quite so scalable... I
> wonder
> if the 'gmeye' app doesn't really stress your constraint solver,
> perhaps?

IIRC the constraint solver is not used there.

> An interesting optimisation that is used by other scenegraph libraries
> (eg Open Inventor) is level of detail (LOD) controls, which when a
> canvas/scene is zoomed out, limits the detail which is drawn for
> certain
> tiny little item on the screen... detail which would have been
> indiscernable, in any case.

That would be as simple as adding the zoom factor to the draw
context ;).

> Cheers
> JP
>
> >

[John Pye]

Arjan Molenaar wrote:
> On 27 Aug 2009, at 16:30, John Pye wrote:
>
>
>> Hi Arjan
>>
>> Arjan Molenaar wrote:
>>
>>> Hi,
>>>
>>> There is the gmeye application, located at http://gaphor.devjavu.com/browser/gmeye
>>> (has to be converted to GIT repo still). It's able to draw a map
>>> (Poland and The Netherlands currently) and highlight the cities.
>>>
>>> I haven't seen a test with items and interconnecting lines though.
>>> It's worth a try :)
>>>
>>>
>> I was figuring that your quadtree way of working out which bits of the
>> canvas need to be drawn/updated would be pretty efficient, but I
>> wasn't
>> so sure if the constraint solver would be quite so scalable... I
>> wonder
>> if the 'gmeye' app doesn't really stress your constraint solver,
>> perhaps?
>>
>
> IIRC the constraint solver is not used there.
>

So we'd want to test a case where a large, constrained canvas was being
used.

>> An interesting optimisation that is used by other scenegraph libraries
>> (eg Open Inventor) is level of detail (LOD) controls, which when a
>> canvas/scene is zoomed out, limits the detail which is drawn for
>> certain
>> tiny little item on the screen... detail which would have been
>> indiscernable, in any case.
>>
>
> That would be as simple as adding the zoom factor to the draw
> context ;).
>

FWIW, OpenInventor does this by registering, ahead of time, multiple
'trees' of objects that can be displayed/enabled/interacted with,
according to LOD rules determined by the engine. In other words, not
just the drawing, but the whole 'mechanism' of the display and
interaction can be varied as a function of zoom level, size on screen,
distance from the observer, a number of rules like that.

Cheers
JP

[wrobell]

On Fri, Aug 28, 2009 at 12:30:58AM +1000, John Pye wrote:
>
> Hi Arjan
>
> Arjan Molenaar wrote:
> > Hi,
> >
> > There is the gmeye application, located at http://gaphor.devjavu.com/browser/gmeye
> > (has to be converted to GIT repo still). It's able to draw a map
> > (Poland and The Netherlands currently) and highlight the cities.
> >
> > I haven't seen a test with items and interconnecting lines though.
> > It's worth a try :)
> >
>
> I was figuring that your quadtree way of working out which bits of the
> canvas need to be drawn/updated would be pretty efficient, but I wasn't
> so sure if the constraint solver would be quite so scalable... I wonder
> if the 'gmeye' app doesn't really stress your constraint solver, perhaps?

It is not, indeed. :)

IMHO, the problem is not solver at the moment.

For example, let's consider some simple operation like moving multiple
items around. Change demo.py to draw more than 50 boxes (I have quite slow
machine, you may want to increase that), it is the code around line 404,
then run demo.py with option '-p'. Start moving the big box around for
a while (i.e. 10s), so the small boxes are being moved as well.

I have got the profiler output

405934 function calls (392668 primitive calls) in 13.973 CPU seconds

Ordered by: internal time, call count
List reduced from 336 to 20 due to restriction <20>

ncalls tottime percall cumtime percall filename:lineno(function)
1 5.439 5.439 13.973 13.973 demo.py:437(main)
16349 0.668 0.000 1.197 0.000 view.py:546(queue_draw_item)
225 0.598 0.003 3.905 0.017 view.py:611(update)
4112 0.559 0.000 0.668 0.000 canvas.py:533(update_matrix)
8087 0.524 0.000 0.634 0.000 view.py:323(update_matrix)
16209 0.415 0.000 0.415 0.000 view.py:563(queue_draw_area)
3937 0.327 0.000 0.411 0.000 inspect.py:735(getargs)
446 0.271 0.001 0.396 0.001 quadtree.py:113(get_soft_bounds)
225 0.264 0.001 0.473 0.002 view.py:504(update_adjustments)
51278 0.258 0.000 0.258 0.000 geometry.py:97(__iter__)
2200 0.192 0.000 0.875 0.000 state.py:209(revert_handler)
1 0.182 0.182 3.009 3.009 demo.py:365(create_canvas)
4332/288 0.178 0.000 0.812 0.003 canvas.py:509(update_matrices)
716 0.165 0.000 0.849 0.001 painter.py:83(_draw_item)
8139 0.157 0.000 0.203 0.000 geometry.py:571(rectangle_clip)
2 0.133 0.067 0.296 0.148 demo.py:105(create_window)
144 0.121 0.001 0.121 0.001 canvas.py:643(_obtain_cairo_context)
3937 0.120 0.000 0.637 0.000 inspect.py:795(getargspec)
8139 0.118 0.000 0.412 0.000 quadtree.py:146(add)
538 0.114 0.000 0.350 0.001 examples.py:24(draw)

I can see here 2 problems at least
- matrix updates - we iterate over each matrix and update it (see
Canvas.update_matrices); it would be really cool to have a function
in Cairo to operate on multiple matrices at once
- we have to improve Rectangle calculations somehow (it looks efficient
enough, but Rectangle.__iter__ is called so many times...)

If I reckon well from my previous attempts to improve Gaphas efficiency,
then normalization is problematic as well. Maybe then the solver... But
it was long time ago. :)

Best regards,

wrobell <wro...@pld-linux.org>