Unable to scroll to bottom of Class Diagram (reproducible)

[Wayne Moorefield]

OSX

StarUML 2.0.2

The scroll bar has a limit so that it does not scroll to end of class diagram in either direction. If I zoom out I am able to scroll to end of diagram. However, if I zoom in I can scroll to even less of the diagram. This seems to be an issue of scrolling not mapped to actual size of diagram but hard coded.

Thank you!

[StarUML]

Hi Wayne,

This is a problem of memory limitation of HTML5 Canvas. When you zoom in, the canvas size also need to be larger but it causes memory problem in Chromium. So it not easy to resolve in near future. Anyway, Thank you for your feedback.

Thanks,

StarUML Team

2015년 2월 20일 금요일 오전 3시 20분 0초 UTC+9, Wayne Moorefield 님의 말:

[fjz...@gmail.com]

Any progress? I DO think it's the most important bug had to be fixed, as it disallow my big project with lot of classes.

I love StarUML，please help!

[Andrzej Sędziński]

I'm experiencing the same problem with limited size of canvas on Windows machine with StarUML v 2.8. Any Chance to solve it? 

[aq zheng]

The same problem on MAC with StarUML v3.1.0. 

在 2016年12月5日星期一 UTC+8下午10:23:08，Andrzej Sędziński写道：

[steve capell]

SarUML 3.1.1 for mac - still have this problem.  very frustrating - cant work with larger models

[Pieter Morrison]

Any update on this - the issue still exists in StarUML 3.2.2 (on Mac anyway).  My diagrams isn't even that large!

[Christian Massow]

Dear StarUML

Can you please respond to this issue? We like StarUML a lot but this bug makes it almost unusable for us. We are working on a modle with less than 40 classes and the class diagram is an important tool for us. With scrolling not working, we will have to look for alternatives. 

What are you doing to fix this; or can't you?

Thank you in advance for your help and information.

Christian Massow

[StarUML]

Hi,

There are two approaches to resolve this problem. First one is extending canvas size, but it will cause system crash (consume too much memories). The second one is implementing scrolling diagram by software in a limited canvas size. It also causes severe performance degradations in unusable level. Please understand it is hard and complex problem because it is implemented in JS (electron), and not native.

At this time, we have no other ways to recommend to divide a big diagram into multiple diagrams, each diagram represents a single particular perspective on the model (OMG UML Specification document is a google example).

Anyway, we will research to extend diagram size and enhance performance and try to resolve this issue in V4 release.

If there is any progress, we will let you know.

Thanks,
StarUML Team


2020년 5월 13일 수요일 오후 9시 50분 47초 UTC+9, Christian Massow 님의 말:

[Aleksandar]

Please excuse me for jumping into the conversation, but why do you need 40 classes in a single diagram? 

When modeling an application, I avoid having more than a couple of classes on a diagram - because I find it difficult to read and understand. In this way, each diagram serves its purpose... 

Do you agree, Christian?

[Nitin Khanna]

I do not agree with this proposal. I am modeling a reasonable simple web application with over 50 classes and uth relationships between them. This bug should be fixed 

[Peter Halverson]

> I am modeling a reasonable simple web application with over 50 classes and uth relationships...

It's not the size of the model that's questionable, but the number of elements ("views", in StarUML) on a single diagram. I struggle to imagine what value anyone could gain from a class diagram with that many elements. Hence the guidance to use multiple diagrams to represent your design, not a single monolithic one. Each diagram would provide a view into a different portion of your model – presentation vs business logic, say, or different relationships that would otherwise overlap each other. That will be much easier for someone to read and understand than a single monolithic view. And, coincidentally, help avoid this particular bug 😉/

[Timothy Brake]

I’m having same issue in a sequence diagram. When drawing a significant real world sequence diagram of a more complex use case then I cannot scroll all the way to the right. Splitting it up into multiple sequence diagrams is just not the acceptable answer here.

I have a paid license so I hope this will be resolved soon as the tool becomes unusable in real world professional complex use-cases.

[StarUML]

Hi,

This issue can be handled at StarUML V4 release. You can manually canvas size as described in the docs: https://docs.staruml.io/user-guide/customization#custom-diagram-canvas-size
This way is not the fundamental solution, but it can be a temporal solution.

Thanks,

StarUML Team

2020년 9월 15일 화요일 오후 7시 45분 1초 UTC+9에 timothy...@gmail.com님이 작성:

[Frank]

In the V4, what's is the max size to use as a good balance. Thanks so much

{

"diagramCanvasWidth": 5000, // Default is 4000

"diagramCanvasHeight": 3500 // Default is 3000

[StarUML]

Default size is the balanced size for performance and size. If you can sacrifice performance, you can increase the size even further. As you know the performance is depends on your computer specification.

Thanks,

2021년 4월 16일 금요일 오후 3시 55분 30초 UTC+9에 biwent...@gmail.com님이 작성:

[Håvard Geithus]

Thanks for all the replies. I must admit I am not satisfied with the explanation given here. Let me explain why:

I use the default settings provided in StarUML 4.0.1 for MacOS (no changes to canvas settings or anything). No extensions installed.

Here is a complete summary of my usage of the app:

1. Installed the app

2. Opened app, and created an ER-diagram with 17 entities, and 13 notes, and a bunch of entity relationships.

At this point everything was fine: I could have any entity enter the viewport completely by scrolling, regardless of zoom level. Just as you'd expect from a scrollable viewport. Performance at this point was completely fine.

3. It was time for a break. So I saved the file. And closed the application.

4. Time to continue. Opened the app, and loaded the file.

At this point I am in the same situation as OP. I can no longer scroll as expected. Some entities can't enter the viewport at zoom level 70%.

The reason I'm suspecting something else is going on here, is due to how the scroll behavior changed simply by closing and restarting the app. As mentioned before, I have not changed any application settings / config files.

My guess is there is something wrong about the calculation of the model height and width when loading a model from file.

Please look into this.

If you're interested I can provide a file.

Thanks,

Håvard Malm Geithus

[Håvard Geithus]

One more thing, possibly unrelated but still...

If I duplicate my *.mdj file and give it another name it won't load properly. It loads differently.

For the duplicated file, the "Main graphical view" only shows the StarUML logo, but the Model Explorer seems fine (all the elements are there). I have verified md5 hash of the two files are the same.

Now, if I right-click an element from the Model Explorer and choose "Select in Diagram", the "main graphical view" suddenly redraws and shows the content.

Why is the loading of a file dependent on the file name?

This reinforces my belief that there's something strange going on when loading a model from file.

Thanks for reading,

Håvard Malm Geithus

[Håvard Geithus]

More details: Here's my minimap. Can't scroll further right. Can't scroll further down.

[Håvard Geithus]

Hi again.

I have simplified my ER Diagram to only contain a single empty entity (i.e. empty column compartment). I call this file foo.mdj

Here's the minimap for foo.mdj at its maximum right-down scrollable position.

The single entity is located at: "left": 2512, "top": 1728. This is well within the bounds of the default canvas size (default size is 4000 x 3000).

As a reference I'm also adding the file foo.mdj:

{
    "_type": "Project",
    "_id": "AAAAAAFF+h6SjaM2Hec=",
    "name": "Project Name",
    "ownedElements": [
        {
            "_type": "ERDDataModel",
            "_id": "AAAAAAF7fapAk7tUUM4=",
            "_parent": {
                "$ref": "AAAAAAFF+h6SjaM2Hec="
            },
            "name": "Data Model Name",
            "ownedElements": [
                {
                    "_type": "ERDDiagram",
                    "_id": "AAAAAAF7fapAk7tVD7c=",
                    "_parent": {
                        "$ref": "AAAAAAF7fapAk7tUUM4="
                    },
                    "name": "ER Diagram Name",
                    "ownedViews": [
                        {
                            "_type": "ERDEntityView",
                            "_id": "AAAAAAF7gXKl076JjtI=",
                            "_parent": {
                                "$ref": "AAAAAAF7fapAk7tVD7c="
                            },
                            "model": {
                                "$ref": "AAAAAAF7gXKl0r6HQ20="
                            },
                            "subViews": [
                                {
                                    "_type": "LabelView",
                                    "_id": "AAAAAAF7gXKl076KjqM=",
                                    "_parent": {
                                        "$ref": "AAAAAAF7gXKl076JjtI="
                                    },
                                    "font": "Source Code Pro;13;1",
                                    "left": 2512,
                                    "top": 1733,
                                    "width": 295.1995849609375,
                                    "height": 13,
                                    "text": "foo"
                                },
                                {
                                    "_type": "ERDColumnCompartmentView",
                                    "_id": "AAAAAAF7gXKl076L+x4=",
                                    "_parent": {
                                        "$ref": "AAAAAAF7gXKl076JjtI="
                                    },
                                    "model": {
                                        "$ref": "AAAAAAF7gXKl0r6HQ20="
                                    },
                                    "font": "Source Code Pro;13;0",
                                    "left": 2512,
                                    "top": 1751,
                                    "width": 295.1995849609375,
                                    "height": 10
                                }
                            ],
                            "font": "Source Code Pro;13;0",
                            "left": 2512,
                            "top": 1728,
                            "width": 295.1995849609375,
                            "height": 271,
                            "nameLabel": {
                                "$ref": "AAAAAAF7gXKl076KjqM="
                            },
                            "columnCompartment": {
                                "$ref": "AAAAAAF7gXKl076L+x4="
                            }
                        }
                    ]
                },
                {
                    "_type": "ERDEntity",
                    "_id": "AAAAAAF7gXKl0r6HQ20=",
                    "_parent": {
                        "$ref": "AAAAAAF7fapAk7tUUM4="
                    },
                    "name": "foo"
                }
            ]
        }
    ]
}

Please fix!

[Håvard Geithus]

Ok,

so I have a temporary solution. Launch StarUML with low resolution on MacOS (with retina display). This improves the situation. But yeah, there's probably a bug in how viewport / scrollbars are calculated on high resolution displays.

[StarUML]

Hello,

Can you provide your .mdj file via email (sup...@staruml.io) to investigate the problem?

Thanks,

StarUML Team

2021년 8월 30일 월요일 오전 3시 54분 59초 UTC+9에 haavard...@gmail.com님이 작성:

[Håvard Geithus]

Hi, file foo.mdj sent via email.

Thanks!

Håvard Malm Geithus

[Vytautas Kirstukas]

Hi,

So whats the status? I'm running StarUML on iMac but using Windows 10. My resolution is 5120x2880 and scaling enabled to 200%. If I change to 100% scaling, then everything works fine.

[StarUML]

Hi,

We're trying to entirely rewrite the way of canvas scrolling by repainting diagrams with origins instead of using HTML element scrolling feature.

This work has many technical huddles to resolve (mainly performance), so it may takes long time (planned in the next major version (V5)).

Thanks,

StarUML Team

2021년 11월 29일 월요일 오후 11시 20분 21초 UTC+9에 kirs...@gmail.com님이 작성: