我正在为矮人要塞游戏开发一个名为Quickfort的工具.Quickfort将csv/xls格式的电子表格转换为Dwarf Fortress执行的一系列命令,以便在游戏中绘制"蓝图".
我目前正在尝试最佳地解决该工具的2.0版本的区域绘图问题.
考虑以下"蓝图",它定义了二维网格的绘图命令.网格中的每个单元格应该被挖出("d"),被引导("c")或者未被开槽(".").在实际使用中可能存在任意数量的不同绘图命令.
. d . d c c
d d d d c c
. d d d . c
d d d d d c
. d . d d c
为了最大限度地减少需要发送到Dwarf Fortress的指令数量,我想找到一组最大的连续矩形,可以形成这些矩形以完全覆盖或"绘制"所有可绘制的单元格.为了有效,所有给定矩形的单元格必须包含相同的命令.
这是比Quickfort 1.0更快的方法:将每个单元格单独绘制为1x1矩形. 此视频显示了两个版本之间的性能差异.
对于上述蓝图,解决方案如下所示:
. 9 . 0 3 2
8 1 1 1 3 2
. 1 1 1 . 2
7 1 1 1 4 2
. 6 . 5 4 2
上面的每个相同编号的矩形表示连续的矩形.最大的矩形优先于可能在其区域中形成的较小矩形.编号/矩形的顺序并不重要.
我目前的方法是迭代的.在每次迭代中,我通过从单元格的所有4个方向延伸,构建可以从每个网格的可绘制单元格形成的最大矩形的列表.在首先对列表进行排序之后,我从找到的最大矩形开始,将其基础单元格标记为"已绘制",并将矩形记录在列表中.在绘制每个矩形之前,检查其基础单元格以确保它们尚未绘制(与先前的绘图重叠).然后我们再次开始,找到可以形成的最大剩余矩形并绘制它们,直到所有单元格都被绘制为某个矩形的一部分.
我认为这种方法稍微优于愚蠢的暴力搜索,但我浪费了很多周期(重新)计算细胞的最大矩形并检查基础细胞的状态. …
有没有办法检测到document.title/ head > title通过Javascript 的更改？我想通过Google Chrome扩展程序内容脚本检测到这一点,因此我无法在目标页面的JS中实际连接执行标题更改的代码.
我发现WebKitMutationObserver理论上应该能够检测到更改head > title,但它并不适用于所有情况:
// set up an observer for the title element
var target = document.querySelector('title');
var observer = new WebKitMutationObserver(function(mutations) {
mutations.forEach(function(mutation) {
console.log(mutation);
});
});
var config = { attributes: true, childList: true, characterData: true };
observer.observe(target, config);
// this jQuery statement fires the observer as expected ...
$('head > title').text('foo');
// ... but this doesn't:
document.querySelector('title').innerText = 'cheezburger';
// ... and neither does this:
document.title = …我正在寻找一种方法来确定Google Chrome扩展程序中给定标签的开启者(父标签).
我已经查看了Tab的文档,但似乎没有任何可以产生这些信息的东西.http://code.google.com/chrome/extensions/tabs.html
我已经尝试将这个内容脚本注入页面(我想我可以将值传递给我的后台页面):
alert(window.opener);
..但它只是产生null.
到目前为止,我提出的最好的方法是跟踪当前关注的选项卡,每当创建新选项卡时,只需假设关注选项卡是新选项卡的开启者/父级.我相信,由于背景标签很少(允许)打开新页面,因此事实上大部分时间都会正确识别父标签.但是,它似乎有点笨拙并且有时可能不准确 - 例如,如果另一个扩展程序打开了一个新选项卡,此方法可能会错误地标识新选项卡的开启者.
我正在尝试确定某种方法来为Chrome标签创建符合以下条件的唯一ID:
我已经做了一些相当激进的研究来找到一个全面的解决方案,但似乎没有什么可以做到的.以下是我尝试的方法,增加功效的顺序:
[location.href, document.referrer, history.length].关于最后一种方法,构造的密钥在所有选项卡中是唯一的,这些选项卡共享公共URL,引用者和历史记录长度.对于浏览器重新启动/会话恢复和关闭/撤消关闭之间的给定选项卡,这些值将保持不变.虽然这个密钥"非常"独特,但有些情况下它很模糊:例如,向http://www.google.com打开的3个新标签都会有相同的密钥(这种事情发生得很漂亮)经常在实践中).
"在会话存储中放置GUID"方法还可以用于在当前浏览器会话期间用于关闭/撤消关闭和重复选项卡情况的相同构造密钥的多个选项卡之间消除歧义.但这并不能解决浏览器重启之间的模糊问题.
通过观察Chrome在哪些窗口中打开哪些选项卡,以及根据预期的"兄弟"选项卡(在前一个浏览器中记录)存在哪个选项卡属于哪个窗口,可以在会话恢复期间部分缓解这种最后的歧义.会话).正如您可能想象的那样,实施此解决方案非常复杂且相当狡猾.并且它只能消除Chrome恢复到不同窗口的相同键控选项卡之间的歧义.这使得相同键控的选项卡可以恢复到同一个窗口,这是不可调和的模糊不清.
有没有更好的办法？在浏览器重启(会话恢复)和关闭/撤消关闭之间存在的保证唯一的浏览器生成的每标签GUID将是理想的,但到目前为止我还没有找到这样的东西.