开发者

Efficiently representing a large grid in a browser

开发者 https://www.devze.com 2022-12-20 13:11 出处:网络
I need to display and manipulate, in a browser, a grid of up to 10,000 simple cells (say, 100 by 100). These cells are basically just a colored-in rectangle. Manipulations include changing cell colors

I need to display and manipulate, in a browser, a grid of up to 10,000 simple cells (say, 100 by 100). These cells are basically just a colored-in rectangle. Manipulations include changing cell colors using Javascript, handling a click on each cell, etc. Using 1 div per cell, and 1 div to wrap groups of cells into a row, I can get down to basically 10,000 DOM elements, but that is still quite a lot. I'm concerned about the performance of even the faster DOM functions, like getElementById.

Initial question: if I store all the necessary DOM element refer开发者_运维知识库ences in a Javascript array (e.g. a 10,000-element array, one element for each cell) and manipulate the CSS on a per-element basis, does this have a prayer of being as quick as it would be when the DOM has, say, 200-500 elements?

So, I'm looking for suggestions of how I might be able to show this 100 x 100 grid more efficiently. I've considered using a canvas and drawing each cell using Javascript, but I'm not sure how much faster this would actually be, especially when it comes time to edit the style of the cells. I'm also not so inclined to go with a canvas because it's not fully cross-compatible (read: @#%$ing IE) and at some point I will probably need to make this thing IE-compatible.

What are your thoughts?


See JavaScript data grid for millions of rows or, in short, use SlickGrid - http://github.com/mleibman/slickgrid


For what it's worth, there's the possibility that you could use borders to have one <div> represent three, or more, areas. Though it would be awkward to ensure cross-browser compatibility (given the differences between Trident, Gecko, Webkit and Presto).

If there's a reason that the cells are, basically, tabular in their presentation you could use a table. Which would simplify things a little, though might be non-semantic depending on your use-case.

Also, personally I'd test creating this, with the options you've got available, for tables, divs, lists (probably ul, but it depends on your use-case of course)...and then just go with what you find is the fastest.

I'd recommend using CSS-sprites for the background/colouring of each cell if they're going to be a predictable height width, just to conserve some bandwidth.


In response to the question in comments:

To have one div generate the colour for three areas, assuming a fixed height/width of each div of 100px.

div#3areas
{width: 100px;
height: 100px;
background-color: #f00; /* for the vertically-centred area */
border-top: 100px solid #00f;
border-bottom: 100px solid #0f0;
}

Should generate something like:

+------------------------+
|                        |
|      border-top        |
|        (#00f           |
+------------------------+
|                        |
|      central content   |
|       area (#f00)      |
+------------------------+
|                        |
|      border-bottom     |
|         (#0f0)         |
+------------------------+

But it probably won't, due to the different ways in which browsers handle borders, see: http://www.cssplay.co.uk/boxes/borders.html (albeit this is rather out-of-date, being written when IE6, Mozilla 1.5 and Netscape 7 were deemed worthy of comment).


jsgraphics demonstrates use of divs for 2d drawing. In the worst case each div is a pixel and it could manage thousands of them on a canvas.

Another alternative is to only display what the user can see at the time. something like virtual scrolling area library might be useful. The idea is to only render (create the divs) for the area the user can see. google

0

精彩评论

暂无评论...
验证码 换一张
取 消