SylvainTI / wwwsqldesigner

Automatically exported from code.google.com/p/wwwsqldesigner
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

The model area should expand dynamically #89

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Add a lot of tables to the model.
2. Align them.
3. If there is not enough space in the default 2000x2000 area not all 
relations are drawn.

What is the expected output? What do you see instead?
The area's size should be enlarged so that the relations can be drawn.

What version of the product are you using? On what operating system?
trunk / Chromium / XP

Please provide any additional information below.
I patched my version by editing the CSS and giving high values to 
OZ.$('area'). This should be done automatically in the JS.

Original issue reported on code.google.com by geompse@gmail.com on 18 Mar 2010 at 4:32

GoogleCodeExporter commented 9 years ago
This makes some sense (although automatic size recomputation should be imho 
done only
after automatic alignment and in no other situations).

Prior to implementation, it might be wise to check what sizes of SVG "canvas" 
are
reasonable within a browser, with respect to performance.

Original comment by ondrej.zara on 19 Mar 2010 at 6:56

GoogleCodeExporter commented 9 years ago
Maybe a minimal size (2000x2000) should be kept, and enlarged only when a table 
(x,y) 
is moved farther (x+w>2000 || y+h>2000) ?

This way the actual behavior is kept in most case, and when the model is too 
large 
relations are still drawn. It so request more performance only when needed.

Original comment by geompse@gmail.com on 19 Mar 2010 at 10:47

GoogleCodeExporter commented 9 years ago
Yes, I imagine this behavior. The question is whether larger SVG elements are
feasible / performant enough.

Original comment by ondrej.zara on 19 Mar 2010 at 11:11

GoogleCodeExporter commented 9 years ago
Tested by setting Area (so SVG) to 500 000 x 500 000
 > SQL.Designer.tables[0].moveTo(499500,499500)

Moving the table, there is no performance issue with Chromium.
In fact that's not the size of the canvas, that's the number of objects and 
relations 
that matters. This is not related to the SVG size.

Test case : build an XML that contains 10 000 tables and load it
 => Might take some seconds to load :)

Original comment by geompse@gmail.com on 19 Mar 2010 at 11:49

GoogleCodeExporter commented 9 years ago
Nice :)

Original comment by ondrej.zara on 19 Mar 2010 at 12:00

GoogleCodeExporter commented 9 years ago
Implemented in r95.

Original comment by ondrej.zara on 22 Mar 2010 at 1:48