Nik said:
Thomas said:
In that case, consider an 80 by 25 cells table instead. After all, it
has cells built-in and the only basic DOM operations you would need is to
change the cell's colors and their text nodes' values.
Makes sense. It's also a trivial change from the code I already have,
which is using an outer div (so, -> table), a div for each row (->tr)
and a span for each cell (->td).
ACK
For the color changing I'm leaning towards generating a stylesheet,
adding rules to it for each foreground/background combination as
required (if not css rule exists create css rule), then switching the
cell's class to match the rule, rather than setting the style directly
on the cells. I understand that this is faster[1] and it also seems more
elegant to me.
[1] <
http://www.quirksmode.org/dom/classchange.html>
It is certainly more elegant in general. That is, if you want only certain
foreground colors and certain background colors like in a terminal, it does
make a certain sense to define classes for those colors. However, note that
most if not all colors commonly used in terminals can also be selected by
name in CSS. So this only appears to make sense if you want to have
specific combinations of foreground and background colors, and ISTM that
would somewhat contradict your specifications of being as flexible as
possible.
I doubt the `className' property it is generally faster, though, as the
`style' property allows setting the style property as if the `style'
attribute was used (to take precedence over all but !important rules, but
the latter is not formally specified [yet?]) instead of deriving its
computed value from the cascade for *all* the class names in the whitespace-
separated list plus considering possible inline `style' properties. Also
note that speed difference, except for that Opera version, is negligibly
small, could be attributed to a measurement error, and the tested browsers
are not the newest versions anymore, some have even met their end-of-life by
now, as the "Page last changed 22 months ago". It stands to reason that
layout engines and DOM implementations become more efficient in new browser
versions, not less. As a rule of thumb, take everything said about client-
side scripting at the Web with a grain, if not a handful, of salt.
This is not too far off what I'm already doing. One thing that I'm not
doing at present is checking the existing text and color values to see
if the cell actually needs to be changed or not.
You should set up a stack (or similar) with references to changed cells
instead. It would probably be much faster than your approach (which
compares string values), even faster than setting a flag on the cell object
in the array (because you only need L iterations for L changed cells as
compared to M×N iterations every time).
Say, if the array looked so:
var cells = [
[{fg: "#abc", bg: "#def", content: "X"}]
];
(i.e, the first cell of the first row contained an "X") you could have
var changeList = [];
If the background color of the cell were to change, like
cells[0][0].bg = "#012";
you could note that in the change list:
changeList.push(cells[0][0]);
Then the update() method would only need to iterate over `changeList'.
(This is obviously slower for single cells than direct DOM access but
probably a lot faster than it for accessing blocks of cells like ncurses
does.)
I would put all of this in one object, though:
var screenData = {
cells: [...],
changes: []
};
HTH
PointedEars
