I´m doing some trials with a large document using Tiny MCE editor, but when I have a large document "charged" on it, I get a very poor performance when I try to do a "focus" action on any part of document.
Things that I´ve tried:
1 - Modify focus event on tiny MCE init (even I have tried to force script execution when a focus event arrives) doing something like this:
setup: function (ed){
ed.on('focus',function(ed, evt) {
throw new Error("Focus stopped!");
});
},
2 - Mminify number of plug-ins that are being loadding on init.
3 - Configure tiny MCE entity encoding to "raw"
But nothing seems to provide any performance improvement.
Any idea about what could be happening with it?
thank you in advance.
Related
I need your advice on a rather simple question - I'd like to draw an image in datagridview cell.
The problem is that the number of rows can be rather big: up to 100 000 of rows, sometimes more than that.
I tried using CellFormating but in this case the grid is blinking. I tried to set DoubleBuffered = true but it got only worse - the window hung and CPU usage was showing 100%. Other controls stopped drawing itself. Moreover it did not help blinking too much (even on several rows).
So I tried to use source DataTable and added a column. Than I filled it with images. But it was a fail: app memory grew very fast on a big datatable and it just crashed.
Also I tried using DataSourceChanged event and settings images like row[cell].Value = . It fires but grid works strange: sometimes it shows images, sometimes it does not. I read that you must set underlying data to make this working but it caused memory problems as I wrote.
I changed image to text so far but certainly I'd like to have moe user-friendly UI.
What can I do in this case? Probably I should give up images or change display logic at all? I.e. use virtual mode. I tried to use it long ago but I had some difficulties so I just skipped this way and my grid is working in non-virtual mode.
Ok, I eventually used CellFormatting event. It looks like blinking has gone away without my help. Images are looking fine.
I’m building a mobile web application, and even though I’m still in a prototyping kind of the process, I’m having a hard time fixing certain performance problems.
The application itself (works all smooth in desktop browsers, but significantly sluggish in Mobile Safari): Hancards webapp prototype. You may login as mifeng:wangwang or create a new user.
The overall clumsy performance could be tolerable though, except for one thing: the browser simply crashes (!) when you open a set page, tap ‘view’ (enlarge all cards) and then try to go back to the previous page.
The code that gets executed when ‘view’ is tapped is this (very sluggish by itself as well; any way to improve it?):
if ($(this).hasClass('big')) {
$('.card').unwrap().removeClass('big flippable').addClass('small');
$(this).removeClass('big');
}
else {
$('.card').wrap('<div class="bigCardWrap" />').removeClass('small').addClass('big flippable');
$(this).addClass('big');
}
And another thing, a pretty weird bug. Very often the ‘word of the day‘ block won’t display the text node for the last element (<div class="meaning">), even though it’s in the code. The text will not show unless you ‘shake’ the DOM anyhow (unticking and ticking back one of the associated CSS properties can also achieve that). This happens in both desktop and mobile Safari browsers.
The code that writes it in there is this:
// While we are here, also display the Word of the day
$.post('ajax.php', {action: 'stuff:showWotd'}, function(data) {
// Decode the received data
var msg = decodeResponse(data);
// Insert the values
$('.wotd .hanzi').text(msg.content[0]['hanzi']);
$('.wotd .pinyin').text(msg.content[0]['pinyin']);
$('.wotd .meaning').text(msg.content[0]['meaning']);
});
I don’t expect you to advice me on how to fix the performance of the whole application (I will probably have to revise the overall scope of the project instead of trying to find workarounds), but I at least would like to see how to solve these two problems. Thank you!
The only performance issue I see in the script is the wrap/unwrap calls - adding and removing elements from the DOM tends to be fairly slow, and you can probably get the same effect by always having a wrapper element and changing its class rather than adding or removing it.
However, the performance issues you are seeing are most likely in your css:
3D transforms can be much faster than 2D due to hardware acceleration. It looks like you already have this, though you do need to be careful about which elements it is applied to
Shadows have real performance issues, especially when animated. Removing them will probably fix most of the slowness.
Rearranging background images can help - A single background image under transparent pages is faster than having a background image for each page.
I have a problem in my app and I don't know if it is normal or not.
I have a textblock in my application that needs to display a large amount of text (2000-4000 chars). Anyway there is a limit of 2048 pixels I think so my text is cropped, this is no problem, I use this : http://blogs.msdn.com/b/priozersk/archive/2010/09/08/creating-scrollable-textblock-for-wp7.aspx .
The problem is that the longer the text the more memory it consumes. Without the very long text hack from the link above, the textblock consumes around 10mb of memory!
If I use the ScrollableTextBlock from the link above, the amount of memory is going even further and can reach up to 30-40 mb.. There is no limit.
So it seems that the memory usage is related with the area that is drawn...
Is there a way to reduce memory usage for long texts? Has BitmapCach anything to do with this problem and can I disable it? You can easily reproduce this problem by just adding a textblock with a very long text and you can check memory usage with this code, you will see that with just 1 textblock with long text, the peak memory goes up by 10mb or more:
long deviceTotalMemory = (long)DeviceExtendedProperties.GetValue("DeviceTotalMemory");
long applicationCurrentMemoryUsage = (long)DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage");
long applicationPeakMemoryUsage = (long)DeviceExtendedProperties.GetValue("ApplicationPeakMemoryUsage");
Debug.WriteLine("### deviceTotalMemory : " + deviceTotalMemory);
Debug.WriteLine("### applicationCurrentMemoryUsage : " + applicationCurrentMemoryUsage);
Debug.WriteLine("### applicationPeakMemoryUsage : " + applicationPeakMemoryUsage);
I came across similar issues when creating Overflow7
The problems I encountered were to do with the fact that if you use a StackPanel inside a ScrollViewer, then the ScrollViewer insists that all of the StackPanel is rendered, not just the visible portion.
I read around and there were 2 general solutions:
use UI virtualization techniques - e.g. VirtualizingStackPanel
use data virtualization techniques - e.g. crafting your own paging
To get round this in Overflow7 I made use of ListBoxes instead of the ScrollViewer/StackPanel combo. The internals part of ListBox use a VirtualizingStackPanel - and this VirtualizingStackPanel renders just whats on the screen, not the entire scrollable client area.
This was a bit "hacky" but worked well. If you have time, then I believe a better solution would be to improve the ScrollableTextBlock implementation so that it uses VirtualizingStackPanel - there are good posts about how to use this on (for example) WPF VirtualizingStackPanel for increased performance
For a large amount of text in a single control it is normal to consume larger amounts of memory than expected. As it was mentioned before, you can page the text or implement dynamic loading, where only chucks of text are loaded for the visible area. That way you won't be keeping a large string in memory.
In your case, caching would be related to re-use and content reloads whenever the user switches to a different page, not to the initial content loading and manipulation process.
I know this is an old question, however I wanted to add one more solution.
http://blogs.msdn.com/b/stankovski/archive/2013/08/27/yet-another-scrollable-textblock-for-windows-phone.aspx
To accomplish my task I have encapsulated the "splitting" logic into a separate class that produces the output as a List of strings. You can then bind that list to your favorite ListBox control and voila, you have a ginormous text block. The splitting logic has been optimized for performance so you'll get a much better processing time then ScrollableTextBlock by Alex. Also, since you can bind the list to any ListBox control that supports virtualization you will have a much more conservative memory footprint.
I have a gwt list grid which i need to show more than 1000 messages.
But it takes 40millsec to display each message. So it is very slow.
Can u help me so that i can show all messages in less time.
Thanks Nagaraju
As Bogdan said paging is your best bet.
However if your requirement strictly needs you to have the 1000+ lines at one time I would reconsider the grid approach.
When you are working with such a large amount of elements an iterative dom "touch" will be dirt slow.
See if you can rather create a component that gets the messages into String form with their markup. Then set the inner HTML once. You can then use something like jquery or gwtquery to attach handlers to the elements in a timely fashion.
Failing that you could use a lazy render method where you render only whats on-screen but that gets much more complicated.
Answering this 2 Year old question Just for Kicks -
GWT has progressed a lot since 2 Years.
GWT provides hell lot of options to User to do performance tuning.
GWT as done a lot of perormance tuning on widgets. GWT 2.5 has Cell
Widgets like CellList/CellTable/DataGrid which make displaying large
data easier , faster and with light weight heavy DOM.
Reference -
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiCellWidgets
Summary -
Cell widgets (data presentation widgets) are high-performance, lightweight widgets composed of Cells for displaying data. Examples are lists, tables, trees and browsers. These widgets are designed to handle and display very large sets of data quickly. A cell widget renders its user interface as an HTML string, using innerHTML instead of traditional DOM manipulation. This design follows the flyweight pattern where data is accessed and cached only as needed, and passed to flyweight Cell objects. A cell widget can accept data from any type of data source. The data model handles asynchronous updates as well as push updates. When you change the data, the view is automatically updated.
In addition, cells can override onBrowserEvent to act as a flyweight that handles events that are fired on elements that were rendered by the cell.
Note -
1) CellTable being capable of displaying large data also come with Pager options and also AutoPage on Scrolling option ( example CellList )
2) Also, if you come across any other performance issues in GWT you can call in the Bazooka features of GWT - SpeedTracer, Logging, Chrome Dev tools Profiling, GWT Light Weight Metrics, Code Splitting, GWT Compiler Metrics, GWT Closure Compiler, Resource Bundling to crush it !!!!
1000 items for a web-based application is too much. Try implementing some sort of paging algorithm. You could look at the PagingScrollTable from gwt incubator ;)
I've got a windows app which draws charts from data points but there is no way to export the data points into a portable format. I tried using AutoIt to access the form controls values but they were concealed by draw functions. I thought with a memory viewer I might be able to view whatever container is storing the chart values, and extract it that way. However, I tried PrcView and HeapMemView but I was disappointed by their search features. I could not locate anything meaningful with these programs because the memory space was segmented so much that I could not tell where the chart data was stored. Does anyone have a suggestion for how to approach this problem?
Firstly try to find another source for the data; it'll possibly be a lot easier.
If there is no choice and this is something that I had to do then I would probably look at hooking the API and catching the Win32 MoveTo / LineTo, and recording / processing them, or possibly API Spying; either way it will be a lot of effort.