Prototyper is too slow on Mac, file size is just 82kb!

Loukas shared this problem 6 years ago
Solved

I have created a prototype with some dynamic panels and some complex conditional logic, but the file size itself is not big at all (just 82kb). However moving things around, adding/editing/deleting takes too much time! I'm working from a Mac (i5, 4gb ram)

Comments (15)

photo
1

Can we take a look at it? It looks like a memory leak. Could you send it to jim.support at justinmind.com please?

photo
1

I sent the prototype, any look into it?

photo
1

Hi Loukas,


We have been trying to reproduce the error and we haven't been able to. Anyway we've seen that you have a lot of dynamic panels. May I ask you why are you defining all your prototype in just a screen with that many panels?

photo
1

I don't get any error, it's just that Prototyper is too slow... I have created these dynamic panels because I want to have keyboard control over the prototype application according to which I will be navigating through it (you can check the conditional logic built there) and I thought that the dynamic panels is the only solution to do that.

photo
1

There are just too many screens. You can reserve more memory to prototyper by editing the file JustinmindPrototyper.ini that is inside the application (ctrl click-> show package contents) and, instead of -Xmx512m set -Xmx1024m

photo
1

It looks your implementation is not well optimized for working with many dynamic panels.


They're a powerful feature but with such bad performance it's frustrating to work with them.


I'm also using many panels for prototyping a Single Page Application and it's very frustrating to have to wait almos a minuto for the actions dialog to appear! I'm losing to much time waiting for JIMP to load/read panels every time I open a dialog or open the file.


Are you doing something for the next version in order to tackle this issues?

photo
1

How many panels do you have in the same screen?

photo
1

At this time about more than 30.

photo
1

My goodness, then it's perfectly normal it gets slow. Imagine a powerpoint presentation with 30 slides inside just one slide. You should split them into screens.

photo
1

I was thinking JIMP worked more like Illustrator photoshop or even Flash. You can have more than this number of layers, nested layers, symbols etc with them being capable of managing memory perfectly well.

photo
1

It also depends on the number of interactions you have. Of course there is still way to improve the performance. And we will eventually do. I was just saying it's normal it gets slow in your case the way Justinmind works right now. Anyway, we'll keep in mind your case when we face how to improve product's performance. As always, thanks so much for your help.

photo
1

The problem I have when openning the action dialog appears to be due JIMP reloading all objects it have loaded already in the app but now tries to load them on the dialog. If such be the case then maybe you need a more clever way to achieve the same task. What about having some kind of just references to the real ones or something similar?

photo
1

It's a bit more complicated than that. What takes time is the graphical framework to paint all the contents.

photo
1

Then maybe what you can do is to implement some lazy loading technique:


You only load references to objects


When the graphic object is visible you load it, when not you don't.


You need to figure out how to know which objects are visible and what are not. This maybe can be achieved by looking at its position and layer order.


This is just my suggestion as outsider without knowledge of JIMP internals.

photo
1

Sure, that's the best approach in this kind of issues. But is rather complex due to the framework (Eclipse) we are using right now. I'm not saying is impossible, just that it will take a lot of time. Even so, I can see we'll need to do something about it eventually.