View Full Version : Ext Designer getting slower as the project grows

22 Jul 2010, 11:42 PM
the larger a project gets, the longer it takes to apply a change which was made. for example when i edit the html property of a panel or drag something around in myproject it takes about 3-4 secons until the action is completed. the designer freezes and in the meantime nothing else can be done which is really annoying. looks like all the project's javascript code is regenerated when you change only one property of a component, this is really annoying for large applications -.-

23 Jul 2010, 12:23 AM
I'm seeing the same thing in my largish 120Kb+ project. I'm starting to look at separate project files to build other parts of my app. I prefer to keep everything in the same project file... but the delay will be too much hassle.

* Can you guys consider a model where the code is not completely regenerated? Perhaps, you could only generate the code when you either export or view code?

23 Jul 2010, 12:30 AM
* as I'm thinking about this...

I'm not sure how you guys are generating the code, but here is an idea:
- perhaps you could store each segment of code (from each obj-node) and edit only the node for which is modified. Then concatenate that code upon export.
- Kind of like having one really big store with all the properties/objects/etc that includes the component nodes info. From that, you could "modularly" export/view the code.

23 Jul 2010, 4:53 AM
Hey guys,

This isn't a bug, so I'm going to move this to the Help & Discussion forum.

@zolex: what you're experiencing is your project view re-rendering itself to show you the config change you've made visually in the Design canvas. On super large, deeply nested views...yes this can be quite slow. Particularly if you run on a slower/older computer. We have a mechanism in place that we will be taking advantage of soon to update the Design canvas via the Ext JS API methods, where applicable. For example, if you update a Panel's title, we would call setTitle() in the API, rather than re-rendering the whole component. Obviously for many configuration options, a re-render is the only option for displaying the modifications on the Design canvas. But for a good portion of other configuration options, we can avoid that cost.

With that said, what you can/should do now is break up your project into smaller pieces. This is very simple to do utilizing the new "Promote to Class" and "Linked Instances" features. You can then design your components in small pieces, which are no doubt much faster to re-render upon configuration changes. And when you want to view the whole "puzzle", you can select back to your main encompassing component (whether that's a Viewport, Panel, etc. etc.) and see it all together. This practice will not only avoid those long-running renders on a regular basis, but it will also structure your project into more re-usable Javascript classes/components, which is really what should be done anyways.

@lorezyra: I like that idea and I will make note of it for sure, but I think the issue at this time is not the code generation...which happens quite fast via compiled XTemplates. The definite issue is what zolex pointed out, which is the re-rendering of the Design canvas itself. When you have dozens and dozens of components that are all being shown and rendered on each configuration change, it only gets slower and slower with every new component you add. Hence my suggestion to break up the deeply nested components and "bring them to the top" as their own top-level component via Promote to Class. Then each piece of the puzzle can be worked on individually with faster render times, and it only promotes better component-oriented development in the end.

23 Jul 2010, 6:50 AM
a special theme which doesn't contains images will also speed up rendering i think...

one more thing i would like to add, designer shouldn't re-render the canvas when we edit a non-visual property, also altering a store etc shouldn't trigger re-render.

23 Jul 2010, 7:05 AM
That is precisely the mechanism we're implementing Joey, although there are some things that cannot easily be manipulated via the API (even non-visual) and would require a re-render. For example, we can reconfigure() a GridPanel with a new Store, but we cannot do so (without a lot of work) with a ComboBox, it would have to be re-instantiated and re-rendered.

23 Jul 2010, 9:07 AM
ok I thought that it has to render the the whole project again. would be nice to be able to disable updating the "view" temporarily so you can work on some properties etc and then enable rendering again, this would really optimize the workflow with ext designer on larger projects.

23 Jul 2010, 9:40 AM
Hey zolex, I saw you submitted this as a feature request suggestion, and I think it's a very good one. Thanks for suggesting it. For clarity (to others at least), the fact is that only the active "top-level" component is rendered in the Design view. So by promoting sub-components up to be a top-level component, you can work on them individually and only see them in the Design view, and not the rest of the project.

23 Jul 2010, 9:44 PM
P.S. nothing to do with the re-render of the Design canvas, but I just committed a change that has sped up the "Code" tab by at least 5-10x. The code itself generates very fast (and thus project exports are still very fast) but the "Code" tab does a lot of work to highlight the javascript syntax. I changed the algorithm of that highlight functionality and so that code view will now generate a lot faster.