Jump to content

SteveBaker

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About SteveBaker

  • Rank
    Newbie
  1. http://www.w3schools.com/cssref/css_units.asp ...really ought to mention that according to http://www.w3.org/TR/CSS2/syndata.html#length-units the inch, millimeter and centimeter units are only going to work as you'd expect on desktop devices. On mobile platforms, the spec says that the browser should consider the typical viewing distance of these devices (ie much closer than a desktop display) and scale the display accordingly. Since there is no standard for what that typical viewing distance might be - device and browser manufacturers are at liberty to pick just about any number they feel like...so all bets are off. So even though you go to all the trouble to say "I WANT THIS TO BE TWO INCHES WIDE!!!" - you'll basically be ignored. Using all of the non-standard <meta> stuff to turn off zooming and to prevent the user from manually zooming - you still get results that are between maybe a half and a third of the size you asked for. Basically, these units are useless. Argh! -- Steve
  2. Many thanks! Yeah - so it looks like the insertRow behavior for a table with a thead and an empty tbody isn't well-described...or at least not well-implemented. It only really says what happens if you insert a row when there are multiple tbody elements (it puts the new row into the LAST tbody) - but it doesn't seem to mention what happens if there is a thead block present. It looks like both Chrome and Firefox behave as if the new element is added after the last row - no matter which section it's in. It's hard to say that this is a "bug" because the spec is unclear - but it is kinda unexpected, and definitely not the "nice" behavior I'd have expected! Anyway, the MDN document does say that you can use insertRow on thead/tbody/tfoot elements - which ought to solve my problem. Thanks for the link to that document! -- Steve
  3. I have an initially empty table with headings, like this: <table id='myTable'> <thead> <tr><th>xxx</th><th>yyy</th></tr> </thead> <tbody> </tbody> </table> How (in JavaScript) do I add a row of cells into the <tbody> section? I assumed that this: document.getElementById('myTable').insertRow ( 0 ) ...or perhaps this... document.getElementById('myTable').insertRow ( 1 ) ...would work - but they both add the new row into the <thead> section - I want to add to the <tbody> section. If I manually add a garbage row into the HTML file for the <tbody>, then insertRow(2) happily adds my new row right after it in the <tbody> section...but I don't want a garbage entry at the top of my <tbody>! I wondered whether I could find the <tbody> element and do an insertRow on the tbody - but the W3Schools docs suggest that you can only use insertRow on an actual <table> element. Any clues?
  4. I'm writing an online game (using the super-sexxy WebGL stuff to do full 3D rendering in the browser). I find that my otherwise fast/smooth 33ms framerate is interrupted with gigantic (200ms to 500ms or more) glitches every few seconds. The behavior is the same in Firefox 4 and Chrome 10 - I can't test it under IE because Microsoft are carefully ignoring WebGL (perhaps hoping that it'll "go away"!)My computer isn't running any other programs while doing this - this is the only tab that's open - there is no change to the on-screen content so the load should be totally constant - and in this particular game, I'm not talking to the network or anything.The only cause for this that I could reasonably guess (although you may know better) would be Garbage collection from JavaScript. So here are my actual questions:* Are there any tools for discovering when the garbage collector is running?* Are there any other ways to confirm this hypothesis?* What are the criteria that tell JavaScript to garbage-collect?* Are there any strategies to either drastically reduce the amount of time that the garbage collector consumes - or perhaps increase the intervals between these massive glitches?I'm trying to minimize or even eliminate the amount of memory I dynamically allocate - but I suspect that there are things that JavaScript is doing behind my back that may be doing dynamic allocations - and I have some 3rd party library code that I don't particularly want to rewrite. -- Steve
×
×
  • Create New...