周末•杭州(文字版)

启程

最近一个月心情烦闷得很,于是更不想做别的事情,只好狠狠地呆在家里看连续剧,什么片子都看,真成了jencce同学说的电视剧之王。直到后来自己都觉得郁闷得有点可怕,于是决定请个假出去散散心。最初的打算是去苏州,后来在群聊的时候碰到阿杜说要BG我东坡肉,于是一口答应下来去杭州。

11月10日,星期六,杜杜今天下午考试。早早地起床,但还是比预想的稍晚了一些,下楼的时候都快八点了。到旁边的超市买了一盒West和一盒红塔山、一瓶果粒橙,还有一些饼干之类的。然后打的去地铁站,到达上海南站时已经快九点半了,很凑巧的错过了九点半的那趟“和谐号”。

还好买票还算顺利,居然还有下一趟开往宁波的T793的站票,途径杭州东站,不过开车时间是11:21分。没有办法,慢慢等吧。买票的时候顺便问了一下还有没有明天返程的票,售票员非常肯定的告诉我没有了,不管怎样,先去了再说,总有办法回来的,大不了晚一天回来。

还好把闪电床头的一本《大话三国》给带出来了,于是在候车厅里找了片空旷的位置坐下来,开始静静的看书。上海南站的候车厅确实设计不错,很自然的阳光,还有许多绿色植物。我一边看书一边吃着雪饼,不知不觉竟然都快饱了。…

Sigh,蓝色理想论坛又被封了

Update:Nice,新公告!

公告:
各位亲爱的会员和网友,在网站发生事件以来,各地的朋友都纷纷为我们献计献策,在此表示衷心的感谢。经过再三的挑选解决方法,选择了一个比较稳妥的方案,网站论坛会在最近二到三天内恢复,请大家耐心的等候。

新的站点会有更加严格的制度和策略,不便之处,还请大家理解.

============================
昨天下午还在蓝色理想论坛看帖子呢,看着看着就无法访问了,一直刷了一个下午都没能刷出来,我还纯真的以为是自己的网络出了问题,今天再次输入论坛地址,却看到如此震撼的公告:

公告:

亲爱的蓝色理想网站及经典论坛的会员朋友们,我们在这里非常遗憾地通知大家,在未来的一段时间里,我们将不能保证经典论坛的正常访问,由于来自外部的不可抗力,论坛服务器所在的机房已对我们进行封网处理,原因是相关监管部门接到举报,在我们的服务器上发现了有害内容,这已经是六天来的第二次封网(一次长沙,一次石家庄)。

Silverlight对MMS的支持并不好

发现自己又错了,才发现Silverlight 1.1 Alpha对MMS协议支持并不完善,仅仅只是能播放和消耗极少的内存而已,而对于流媒体播放的一些事件开始变得奇怪。

播放MMS流时,只是有播放缓冲,即缓冲百分比和下载百分比会迅速变成100%,随即开始播放,而更奇怪的是,当播放一个自动换头的MMS流时,其播放状态不再是和HTTP流一致。在HTTP流中,在换头时,有播放事件Media Ended,而播放MMS流结束后并不会触发这个事件,而是把播放状态(Current State)改变为Paused,此时若在程序中更改MMS流的地址,则会触发一个Media Ended事件。

另外,对于MMS和HTTP流的支持,在Silverlight 1.0的SDK中是这么说的:

Streaming
In addition to progressive downloads, MediaElement supports live and on-demand

Silverlight中XmlReader解析XML的流程

在Silverlight 1.1中,C#只能用XmlReader这样一个非常轻量级的东西来解析XML,因此稍有不慎就会出现很多非常奇怪的错误,在这里对XML的解析做一个简单的流程介绍吧。

在对流式XML的解析中,XmlReader对XML节点进行一些区分,这些节点的类型包括:

public enum XmlNodeType
{
None = 0,
Element = 1,
Attribute = 2,
Text = 3,
CDATA = 4,
EntityReference = 5,
Entity = 6,
ProcessingInstruction = 7,
Comment = 8,
Document = 9,
DocumentType = 10,
DocumentFragment = 11,
Notation = 12,
Whitespace = 13,
SignificantWhitespace = 14,
EndElement = 15,
EndEntity = 16,
XmlDeclaration

这就是PPStream的概念版网络电视?


点这里查看演示

用Silverlight做的,当然了,它真的只是个概念版,无论点哪个节目看的都是同一个视频,看到的都是相同的节目信息,貌似只是简单地请求服务器上的一个视频文件而已。

可能PPStream正在为此而努力吧?

PS:在观看之前可能会要下载部分东西,不明白是干什么用的,又没有启动P2P模块………

Silverlight Alpha 1.1十一月份不会过期

现在从官方网站上下载Silverlight 1.1 Alpha Refresh再装上就不会有过期时间了,对比了一下版本号,两者的版本号分别如下:

原先的版本:
Microsoft Silverlight
Version: 1.1.20813.0
(c) 2007 Microsoft Corporation. All rights reserved.

现在的版本:
Microsoft Silverlight
Version: 1.1.20926.0
(c) 2007 Microsoft Corporation. All rights reserved.

根据官方网站上的说明,Silverlight 1.1的最新版应该是September的Alpha Refresh,但是奇怪的是安装界面上写的居然是“July 2007”………

Silverlight 1.1 Alpha & VS 2008 Beta 2 将于11月1日过期

偶然因为一台计算机的系统时间错误发现的,后来发现其实在Silverlight的License里就说明了:

3.TERM. The term of this agreement is until November 1, 2007 or commercial release of the software, whichever is first.

从MSDN blog上看到说VS 2008的过期时间也是11月1号,只知道内部消息说VS 2008已经有RTM版了,估计11月份会发布VS 2008,不知道十一月份是不是会发布Silverlight 1.1的Beta版?如果是这样的话那就太好了,只剩两天了,如果不发布就只有改系统时间了………

Silverlight播放视频最好选择MMS协议

写了个东西,发现内存的使用会一直上涨,和内存泄漏的状况差不多,一个小时以后内存可以长到300多兆,虚拟内存可以达到300~500兆,然后CPU到使用率也非常的高。后来想想C#有内存自动回收机制,问题应该不会在C#上,那估计就是Silverlight播视频的问题了。

于是用同样一部电影分别开了两个服务:一个HTTP服务,一个MMS服务,然后Silverlight用两种方式来播放这部电影。测试结果非常的明显:

对于使用HTTP协议的视频,内存可以迅速涨到200多兆,然后内存的增长速度几乎就是下载速度,每秒十几兆的增加,缓存增长速度相对内存增长速度则显得非常之慢。

对于使用MMS协议的视频,内存在一直维持在37兆,偶有跳动,但一直在37兆左右跳动,半个多小时都不曾增加内存使用,而且CPU使用率明显低于使用HTTP方式请求视频。

不知道Silverlight是不是把基于HTTP请求的视频直接下载在内存中,然后把播放过的写入虚拟内存?…

Path的Stroke和Fill属性不能指向同一个SolidColorBrush对象?

今天碰到这个BT的问题,对于两个Path对象,像下面这样写的时候,第二行居然无效!

SolidColorBrush scb = new SolidColorBrush(CommonApp.Instance.PathColor);
pathA.Stroke = scb;
pathB.Stroke = scb; //此句居然没有任何作用……

同样,Path的Fill属性存在同样的问题。而对于Rectangle等对象这样写则没有什么问题,真是奇怪…

SolidColorBrush scb = new SolidColorBrush(CommonApp.Instance.RectangleColor);
rectangleA.Fill = scb;
rectangleB.Fill = scb;

这是为什么呢?…

HttpWebRequest头部可用设置以及可读设置

注意:这是在Silverlight 1.1 Alpha中粗略测试的结果,如有错误,欢迎指正!

Alpha还是Alpha,连HttpWebRequest都这么不成熟,最常用的timeout属性居然既不能设置也不能更改,实在是郁闷!花了点时间,把所有的属性的读和写都测试了一遍。

能写的属性如下(其中被注释的表示不能写):

request.Accept = “text/*”;
//request.Address.ToString(); readonly
//request.AllowAutoRedirect = true;
//request.AllowWriteStreamBuffering = true;
//request.AutomaticDecompression
request.Connection = “Close”;
request.ContentLength = 256;
request.ContentType