Hi!
I have been using RadEditor for ASP.NET for one year now and is currently looking at the possibilities to upgrade to the new Prometheus release.
In some parts of my application I use a lot of editors on each page (10 - 15) but with rather minimalistic functionality. I use undo/redo/bold/italic/underline in the toolbar, one context menu for copy/paste, no need for spell checking and no need for any image- or document managers. The loading time is always an issue in this case. When testing the Prometheus version i find that the editors turns up very quickly on the page, but it takes time to initialize them (about 2-2.5 sec) and display the content. Actually, the total loading time for the page in this scenario is virtually the same as for the old version. Is there a way to reduce the time to initialize the editors in this case? I guess this minimalistic editor configuration is not the most common among your customers, but for us, and our customers, it would be very nice if the loading time could be further optimized for this scenario. Since we get some complaints from our customers about the loading time we are concidering other, simpler editors with faster loading speed for this part of the application, but since we also want to be able to use the full editor functionallity in other parts, we would like to keep the RadEditor throughout our complete application.
I am currently using one Toolbar for all editors on the page, moving them to a specified div on the page, as described in http://www.telerik.com/community/forums/thread/b311D-btggg.aspx. How can this be achieved with the Prometheus RadEditor? I also think this would be a nice feature to add to the product, with the divID as a property for the editor,or as a ClientSide API function.
When ToolbarMode is set to ShowOnFocus the toolbar is automatically displayed for the last editor on the page when loaded. How can this functionallity be disabled?
I have used an autoresize function in my application and the new AutoResizeHeight property is welcome but it has one flaw in the current version.
If the initial scrollheight is higher than the editor height, the editor is not automatically resized to display all text when loaded. This is done when the editor gets focus.
Why do I need to add the .tdf files in App_Data/RadSpell even when RadSpell is not enabled in the application?
Finally i think the Prometheus RadEditor will generally be a great improvement, but for us the loading time is still crucial for our decision to upgrade.
I have been using RadEditor for ASP.NET for one year now and is currently looking at the possibilities to upgrade to the new Prometheus release.
In some parts of my application I use a lot of editors on each page (10 - 15) but with rather minimalistic functionality. I use undo/redo/bold/italic/underline in the toolbar, one context menu for copy/paste, no need for spell checking and no need for any image- or document managers. The loading time is always an issue in this case. When testing the Prometheus version i find that the editors turns up very quickly on the page, but it takes time to initialize them (about 2-2.5 sec) and display the content. Actually, the total loading time for the page in this scenario is virtually the same as for the old version. Is there a way to reduce the time to initialize the editors in this case? I guess this minimalistic editor configuration is not the most common among your customers, but for us, and our customers, it would be very nice if the loading time could be further optimized for this scenario. Since we get some complaints from our customers about the loading time we are concidering other, simpler editors with faster loading speed for this part of the application, but since we also want to be able to use the full editor functionallity in other parts, we would like to keep the RadEditor throughout our complete application.
I am currently using one Toolbar for all editors on the page, moving them to a specified div on the page, as described in http://www.telerik.com/community/forums/thread/b311D-btggg.aspx. How can this be achieved with the Prometheus RadEditor? I also think this would be a nice feature to add to the product, with the divID as a property for the editor,or as a ClientSide API function.
When ToolbarMode is set to ShowOnFocus the toolbar is automatically displayed for the last editor on the page when loaded. How can this functionallity be disabled?
I have used an autoresize function in my application and the new AutoResizeHeight property is welcome but it has one flaw in the current version.
If the initial scrollheight is higher than the editor height, the editor is not automatically resized to display all text when loaded. This is done when the editor gets focus.
Why do I need to add the .tdf files in App_Data/RadSpell even when RadSpell is not enabled in the application?
Finally i think the Prometheus RadEditor will generally be a great improvement, but for us the loading time is still crucial for our decision to upgrade.
Best regards
Östen Lundahl
9 Answers, 1 is accepted
0
Andreas Kaech
Top achievements
Rank 1
Rank 1
answered on 09 Jan 2008, 11:21 AM
Hi Östen,
I have a remark to your feedback.
The following issue appears only in IE:
"When ToolbarMode is set to ShowOnFocus the toolbar is automatically displayed for the last editor on the page when loaded."
Best regards,
Andreas
I have a remark to your feedback.
The following issue appears only in IE:
"When ToolbarMode is set to ShowOnFocus the toolbar is automatically displayed for the last editor on the page when loaded."
Best regards,
Andreas
0
Hello Andreas,
Up to your questions:
1. Optimizing the new Prometheus editor vs the Classic editor was planned as a two-step process.
Step 1 - optimize and reduce time to fetch resources mostly by the server by reducing the sheer number of requests (e.g. use a single image sprite for all editor tools, etc). This step is almost complete - some script files are yet to be merged to bring their number even further down. The time could be further improved by using a RadScriptManager control on the page instead of the regular ScriptManager control.
Step 2 - where we will focus more efforts in the coming Q is preventing certain files from loading (such as the AjaxSpellchecker) and loading them only on demand - if the functionality is requested. In addition to this we plan on getting some time-consuming code out of the initialization process and executing it after the page has loaded. The third possibility for optimizing code comes from the fact that it appears that the javascript inheritance mechanism provide by MS AJAX works quite slow - and RadEditor tools rely heavily on it. We are looking into ways to improve on this too.
You will soon see further improvements in the editor in this area as we plan to address sepcifically scenarios with many editors on the page that share the same set of tools.
2. The problem with "ToolbarMode is set to ShowOnFocus" that you report is fixed, and it will appear in the Q3 SP1 build to be released today or tomorrow.
3. AutoResizeHeight - If the initial scrollheight is higher than the editor height, the editor is not automatically resized to display all text when loaded. You are correct. This problem has been fixed as well.
4. You do not need the .tdf files in App_Data/RadSpell when RadSpell is not enabled. However, this tool is enabled in the built-in default editor ToolsFile.xml. Thus, you need to change the default tools file or locate and remove the tool manually using the editor's serverside API.
Kind regards,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Up to your questions:
1. Optimizing the new Prometheus editor vs the Classic editor was planned as a two-step process.
Step 1 - optimize and reduce time to fetch resources mostly by the server by reducing the sheer number of requests (e.g. use a single image sprite for all editor tools, etc). This step is almost complete - some script files are yet to be merged to bring their number even further down. The time could be further improved by using a RadScriptManager control on the page instead of the regular ScriptManager control.
Step 2 - where we will focus more efforts in the coming Q is preventing certain files from loading (such as the AjaxSpellchecker) and loading them only on demand - if the functionality is requested. In addition to this we plan on getting some time-consuming code out of the initialization process and executing it after the page has loaded. The third possibility for optimizing code comes from the fact that it appears that the javascript inheritance mechanism provide by MS AJAX works quite slow - and RadEditor tools rely heavily on it. We are looking into ways to improve on this too.
You will soon see further improvements in the editor in this area as we plan to address sepcifically scenarios with many editors on the page that share the same set of tools.
2. The problem with "ToolbarMode is set to ShowOnFocus" that you report is fixed, and it will appear in the Q3 SP1 build to be released today or tomorrow.
3. AutoResizeHeight - If the initial scrollheight is higher than the editor height, the editor is not automatically resized to display all text when loaded. You are correct. This problem has been fixed as well.
4. You do not need the .tdf files in App_Data/RadSpell when RadSpell is not enabled. However, this tool is enabled in the built-in default editor ToolsFile.xml. Thus, you need to change the default tools file or locate and remove the tool manually using the editor's serverside API.
Kind regards,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Thomas Booysen
Top achievements
Rank 1
Rank 1
answered on 01 Feb 2008, 07:42 AM
"Step 1 - optimize and reduce time to fetch resources mostly by the
server by reducing the sheer number of requests (e.g. use a single
image sprite for all editor tools, etc)."
Hi
Do the optimizations mentioned apply to the non-Prometheus ASP.NET RadEditor as well? Specifically using a single sprite image instead of gazillion smaller ones? Our applications will need to support the older RadEditor for a while longer and currently the RadEditor is a bit of a performance problem.
0
Hi Thomas,
Most new development is aimed at the RadEditor Prometheus, especially the performance optimizations. We just finished implementing the Telerik Prometheus Core optimizations, and some of the script optimizations planned for the RadEditor Prometheus control itself. The SP2 scheduled for end of February will feature a faster loading editor, as well as the ability to strip additional "weight" off it by configuring some properties.
We are also about to release RadEditor Prometheus for DNN and for MOSS (SharePoint).
It is possible to implement the "sprite" rendering for the RadEditor Classic as well, the only thing that is stopping us from doing it is the fact that that would affect a lot of functionality and can introduce some breaking changes to people who implemented custom tools (which is quite a few).
Once the DNN amd MOSS versions are available, switching to RadEditor Prometheus should be fairly straightforward, as the two editors's feature set is almost identical.
Can you provide is with more information about the reasons that are holding you back from switching - so that we get a clearer picture and see how we can help you best?
Sincerely yours,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Most new development is aimed at the RadEditor Prometheus, especially the performance optimizations. We just finished implementing the Telerik Prometheus Core optimizations, and some of the script optimizations planned for the RadEditor Prometheus control itself. The SP2 scheduled for end of February will feature a faster loading editor, as well as the ability to strip additional "weight" off it by configuring some properties.
We are also about to release RadEditor Prometheus for DNN and for MOSS (SharePoint).
It is possible to implement the "sprite" rendering for the RadEditor Classic as well, the only thing that is stopping us from doing it is the fact that that would affect a lot of functionality and can introduce some breaking changes to people who implemented custom tools (which is quite a few).
Once the DNN amd MOSS versions are available, switching to RadEditor Prometheus should be fairly straightforward, as the two editors's feature set is almost identical.
Can you provide is with more information about the reasons that are holding you back from switching - so that we get a clearer picture and see how we can help you best?
Sincerely yours,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Thomas Booysen
Top achievements
Rank 1
Rank 1
answered on 06 Feb 2008, 07:17 AM
Hi Tervel
Our products are almost ready to ship so we can't afford to introduce any unknowns at this point. I was just hoping to get a free performance win :) I've investigated the Prometheus Editor and I'm happy with the performance enhancements made so far, so I'll definitely be pushing the change over as soon as possible.
0
SamVanity
Top achievements
Rank 2
Rank 2
answered on 07 Apr 2008, 06:35 AM
I just want everyone to know that if you are designing your application that allows your users to use the Prometheus Editor (like this support forum), you need to be aware that the server rendering performance of this Prometheus Editor is at least 30 times slower than the regular version (0.3 second v.s. 0.01 second).
I supplied Telerik with a very simple project (only B, I and U on the toolbar) comparing the performance of the regular RadEditor and this Prom version, and due to the use of reflection to render on the server side, there is nothing Telerik can or wants to do at this moment to rectify this performance issue.
However, if you are the only one or there are only selected few that are gonna use the editor on your site, you should be fine. But in my case, where there could be thousands of users on the application at any given time (several of my clients are using my application in this manner), I cannot use this new version.
I supplied Telerik with a very simple project (only B, I and U on the toolbar) comparing the performance of the regular RadEditor and this Prom version, and due to the use of reflection to render on the server side, there is nothing Telerik can or wants to do at this moment to rectify this performance issue.
However, if you are the only one or there are only selected few that are gonna use the editor on your site, you should be fine. But in my case, where there could be thousands of users on the application at any given time (several of my clients are using my application in this manner), I cannot use this new version.
0
Hello,
Here is some additional information that could be useful to forum readers:
===================================================
The serverside time it takes for the editor to render is bigger in RadEditor Prometheus compared to RadEditor Classic, because the RadEditor Prometheus is built on top of the MS AJAX framework.
The MS AJAX framework uses the .NET reflection mechanism for dynamic introspection of properties to build the initialization string that gets sent to the clientside to initialize the clientside counterpart of the control.
Reflection is different than running compiled code by about 10 times. However, this cannot be changed, as it is the way MS AJAX framework works.
The result is, that it will not be possible to make editor server-rendering significantly faster.
===================================================
Depending on the serverside configuration, the Prometheus Editor will be processed several times slower.
it is important to note, however, that on the client-side the Prometheus editor due to its client optimized rendering loads in just 25% of the time needed for RadEditor Classic, e.g. it loads 4 times faster. There is always a tradeoff involved, but in rich-functionality controls the client-side performance tends to be of utmost imporance [judging by developer feedback].
That said, with the official release of the Prometheus suite, we will profile the MS AJAX framework code, and investigate the possible ways of decreasing the time it takes [for MS/AJAX/Prometheus controls] to load on the server.
All the best,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Here is some additional information that could be useful to forum readers:
===================================================
The serverside time it takes for the editor to render is bigger in RadEditor Prometheus compared to RadEditor Classic, because the RadEditor Prometheus is built on top of the MS AJAX framework.
The MS AJAX framework uses the .NET reflection mechanism for dynamic introspection of properties to build the initialization string that gets sent to the clientside to initialize the clientside counterpart of the control.
Reflection is different than running compiled code by about 10 times. However, this cannot be changed, as it is the way MS AJAX framework works.
The result is, that it will not be possible to make editor server-rendering significantly faster.
===================================================
Depending on the serverside configuration, the Prometheus Editor will be processed several times slower.
it is important to note, however, that on the client-side the Prometheus editor due to its client optimized rendering loads in just 25% of the time needed for RadEditor Classic, e.g. it loads 4 times faster. There is always a tradeoff involved, but in rich-functionality controls the client-side performance tends to be of utmost imporance [judging by developer feedback].
That said, with the official release of the Prometheus suite, we will profile the MS AJAX framework code, and investigate the possible ways of decreasing the time it takes [for MS/AJAX/Prometheus controls] to load on the server.
All the best,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Ian Russell
Top achievements
Rank 1
Rank 1
answered on 29 May 2008, 10:57 PM
Is there any work around to improve performance? When I paste an HTML of ~28K in size and switch to design mode it takes twice longer with AJAX version than the non-AJAX one. It really makes the AJAX RadEditor unusable. Is there a way to at least display a loading panel while switching between design and HTML modes?
0
Hi Attila,
The problem with the delay comes from the fact that the editor runs a great deal of client-side filters (about 15) that convert the non-XHTML content produced by the rich-edit browser engine into XHTML content. The more content has to be converted, the more time it takes.
Regarding your request - it is quite hard to make a loading panel to provide the same visual effect as when using AJAX. Why? When making an AJAX call a request goes to the server, and the client-side CPU is not busy so the rest of the browser can work "normally" - e.g. it can provide visual feedback to the user. On the other hand - when a CPU intensive operation runs on the client (e.g. the conversion of non-XHTML to XHTML) the browser becomes busy with executing the script and the browser almost "freezes" - thus "freezing" the animated .GIF images that provide visual feedback to the user.
Nonetheless, if the filtering mechanism is reworked to use timeouts, then it will be possible to provide such smooth feedback to the user. We agree with you that this is a valuable suggestion, and we logged it for implementing. Since it will require a more substantial rework and testing of the current mechanism, we cannot give you an ETA when it will be ready.
Thus, the only solution at present to reduce the time it takes for the editor to handle this much content is to turn off some or most of the client-side content filters. This will prevent the editor from producing XHTML, but it will greatly increase its speed. The following example on built-in filters will provide you with extra information:
http://www.telerik.com/DEMOS/ASPNET/Prometheus/Editor/Examples/BuiltInContentFilters/DefaultCS.aspx
Greetings,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
The problem with the delay comes from the fact that the editor runs a great deal of client-side filters (about 15) that convert the non-XHTML content produced by the rich-edit browser engine into XHTML content. The more content has to be converted, the more time it takes.
Regarding your request - it is quite hard to make a loading panel to provide the same visual effect as when using AJAX. Why? When making an AJAX call a request goes to the server, and the client-side CPU is not busy so the rest of the browser can work "normally" - e.g. it can provide visual feedback to the user. On the other hand - when a CPU intensive operation runs on the client (e.g. the conversion of non-XHTML to XHTML) the browser becomes busy with executing the script and the browser almost "freezes" - thus "freezing" the animated .GIF images that provide visual feedback to the user.
Nonetheless, if the filtering mechanism is reworked to use timeouts, then it will be possible to provide such smooth feedback to the user. We agree with you that this is a valuable suggestion, and we logged it for implementing. Since it will require a more substantial rework and testing of the current mechanism, we cannot give you an ETA when it will be ready.
Thus, the only solution at present to reduce the time it takes for the editor to handle this much content is to turn off some or most of the client-side content filters. This will prevent the editor from producing XHTML, but it will greatly increase its speed. The following example on built-in filters will provide you with extra information:
http://www.telerik.com/DEMOS/ASPNET/Prometheus/Editor/Examples/BuiltInContentFilters/DefaultCS.aspx
Greetings,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center