Today's the day

respond_to 新构想

respond_to 非常好用，可以根据不同的 format 来选择不同的应答策略，并且自动设置相应的 MIME 值，看上去也非常爽目。

在 Blog 系统中，比如文章的 RSS，就可以：

def index
@posts = Post.find(:all)
respond_to do |format|
format.html { ...}
format.rss {...}
end
end

这样比在单独构建一个 RSS action 要好得多～

不过，如果 Blog 通过 html 显示出来的话，还需要做其他一些事情，比如构建 Blog 的各个边栏，这些事情一般都放在 before_filter 中去做：

class PostsController < ApplicationController
before_filter :get_sidebars
...

但是这些工作在 RSS 中完全不需要，那么怎么在 RSS 忽略掉这些工作呢？

一个选择就是去掉 before_filter，把 get_sidebars 写入到 format.html { } 中去，这样的话，PostsController 里面每个 action 的 format.html 都要这样做，不是啥好办法。

第二个选择就是在 get_sidebars 里面检测 format：

def get_sidebars
if params[:format] == "html"
...create sidebars

这样似乎还算 ok，其他的方法还没有想出来……

前两天，正好看到 maiha 写的新 respond_to 表示方法的构想，去掉 respond_to 那个 block，而按照 aciton.format 的格式，把不同 format 的处理，放到单独的函数中去：

def index
@posts = Post.find(:all)
end
def index.html
...
end
def index.rss
...
end

这样看上去比 respond_to 清晰了很多，如果可以实现，那么如果在 before_filter 里面也可以：

before_filter :get_sidebars, :only => "*.html"

就能完美的解决上面的问题了～

糟糕的 Nvidia Linux 驱动？

汗，是不是写错了？ Nvidia 的 Linux 驱动不是一直广受赞誉，印象中 ATI 的 Linux 驱动才一直是很糟糕。

但是现在状况似乎有些变化……

如果你正在 Linux 上使用一块 Nvidia 的比较新的显卡，比如 8000 和 9000 系列，也许你遇到下面这些问题：

Firefox 在浏览某些网站的时候，拖动起来非常卡 ( 比如: http://www.tuaw.com ) ；切换标签页的时候也很卡。
调整应用程序窗口尺寸的时候，会非常卡。
KDE 4/ Qt 4 程序卡得基本没法用。
虽然可以流畅的跑 Compiz，但是某些特效会很卡，包括缩放窗口。

嗯嗯，也许你一直抱怨 Firefox 的性能不好，KDE 4 很慢，其实都不是，罪魁祸首是 Nvidia 的 Linux 驱动……

不管是 169、173，还是最新的 177 beta 驱动，都在 8000 和 9000 系列显卡上表现出很糟糕的 2D 性能。3D 性能还是很完美的，所以你可以流畅的玩 Doom，但是却不能流畅的浏览网页。

详细的情况可以参考 Nvnews 论坛的帖子：

nVidia 8000/9000 Series Performance Issues

从上面的帖子可以看出，受难的人真不少，甚至还波及到了某些 7000 和 GT200 系列显卡。

暂时的缓解方法

当然最好的情况就是 Nvidia 能够听到 Linuxer 的心声，在新版的驱动中修正这个严重的 bug，目前只好等待。闭源驱动的弱点，充分的展现了出来……

国外的网友尝试出一些缓解上面这些问题的设置，如果你正在被上面的问题所困扰，可以尝试一下，效果在不同的显卡上差异很大，但是总体上都会有不少的改善。

首先，安装最新的 177 beta 驱动，然后尝试运行：

nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

如果你正在使用 177 的驱动并且正在运行着桌面，那么可以直接在终端窗口运行此命令，不需要重启 X。

我的显卡是 8600GTS，运行上面的命令之后，窗口缩放的性能变得可以接受了，如果对你也有效的话，可以把上面的命令添加到 ~/.xinitrc 中。

另外，还可以在 xorg.conf 中的 Section "Device" 中加入：

Option "PixmapCacheSize" "300000"
Option "OnDemandVBlankInterrupts" "True"

然后重启 X，在我这里，重启 X 后，Firefox 拖动网页卡的现象大大缓解了。

如果你想比较流畅的运行 KDE 4，那么可以参考一下：

http://techbase.kde.org/User:Lemma/GPU-Performance

上面也列出了一些 8000 之后显卡支持的 Option 选项，可以尝试打开后看看效果：

Options that are said to work well on 8xxx cards but are untested (by me)

Option "RenderAccel" "True"

enabled by default

Option "TripleBuffer" "True"

Enables triple buffering. "Decreases the time an application stalls while waiting for vblank events, but increases latency slightly" (NVIDIA Readme)

Option "DamageEvents" "True"

Recommended by NVIDIA if running composite+glx, increases performance, enabled by default

Option "UseCompositeWrapper" "True"

Enables the X server's composite wrapper instead of the builtin one.

Option "AllowIndirectPixmaps" "True"

Could improve hardware rendering on G80+ cards with more than 256 MB of video memory.

Option "BackingStore" "True"

Cache overlayed areas in case they get redisplayed later

Option "PixmapCacheSize" "200000"

allocate said number of pixels for pixmap caches

也可以定期关注一下前面的 Nvnews 帖子，上面也会不断更新一些最新的解决办法，你也可以把你的显卡型号，和上面这些措施的效果 post 到上面去分享一下。

Nvidia or ATI？

我手上没有 ATI 显卡，不知道 ATI 显卡的情况会好多少，不过如同上面 Nvnews 帖子的作者所说，他帮朋友在 Linux 上装了块 ATI 显卡，并且 “... the performance was amazing all round. 2D/3D Linux/Windows, everything”。

看来，现在情况确实有些变化，虽然 Nvidia 显卡在 Linux 上的 3D 性能有一些优势，但是毕竟 2D 性能才是日常应用的关键，并且 ATI 的驱动也在不断进步，3D 性能不济的状况也比以前大大改善了。

如果你正要装机运行 Linux，并且不会在 Linux 上天天玩 3D 游戏的话，那么至少在 Nvidia 修正这个 bug 前， ATI 是比 Nvidia 更好的选择。