KeyFansClub
Miliardo - 2005/9/30 20:59:00
[lunariss=BG044AN1,,cgus10,,msgbox,14]［汐］Lunariss合成系统现在的最大缺陷……%0D%0A个人认为主要是字体问题……%0D%0A希望增加一些黑体一类适合这个系统的字体，%0D%0A还有像Gothic这样的日语字体，提供选择。[/lunariss]
[lunariss=BG012Y,,cgry21b,,msgbox,14]［椋］同意的请举个手吧。%0D%0A实现难度不会很高的。%0D%0A我也仅仅是希望Lunariss能够更好。[/lunariss]
watashia - 2005/9/30 21:16:00
[lunariss=caodi,,yingwen,,bg,13]黑体是可以了，日文觉得就没有什么必要了。[/lunariss]
碇 - 2005/9/30 21:28:00
这个，推一把...我倒只觉得能设置字体大小会比较好
要加上字体的参数吧，字体选择的控件找找看应该有现成的，貌似见过...
<---BCB使用者
悠久ノ風 - 2005/9/30 21:34:00
[lunariss=02,,03,,msgbox,1]是觉得楷体不好看吗？..不过服务器上实在也%0D%0A没有其他什么更好看的字体了，而且又不是可%0D%0A以随意安装新字体的..（实在不觉得黑体会比%0D%0A楷体好看..）[/lunariss]
[lunariss=02,,04,,msgbox,1]而且..毕竟是一个面向普通用户的在线系统，%0D%0A在功能性和易用性上也得有所取舍。总不会每%0D%0A次贴一张图都要输入一大堆参数吧。[/lunariss]
watashia - 2005/9/30 21:46:00
[lunariss=deguo,,tomo,,bg,13]啊，不高兴了%0D%0A生气了%0D%0A被教训了[/lunariss]
悠久ノ風 - 2005/9/30 21:50:00
[lunariss=02,,02,,msgbox,1]没有没有..（微笑%20%3D%20%3D）%0D%0A%0D%0A只是觉得不是很必要..黑体我原来试过的，图%0D%0A形化后就不是那么容易看清楚了。[/lunariss]
碇 - 2005/9/30 21:58:00
= =b
我没别的意思的
随便提一句而已，请无视吧
看到Dephi里有现成的字体下拉列表框，不过字体...确实不怎么需要了
如果是字号可以用一个普通的下拉框...（比如表现吼的时候字号变大）
悠久ノ風 - 2005/9/30 22:03:00
那个..要让对话里的每个字都能自定义字号的话请考虑一下执行效率..毕竟现在已经慢得要死了 - -
而且GET方法的参数长度是及其有限的..功能太强大的话会爆掉的 - -
总之，二次元合成暂时就不用太复杂了..
以后做AVG.NET的时候再把这些功能都加上去好了 T.T
03534 - 2005/9/30 22:55:00
看惯楷体的某…………
其实……比起功能，某觉得也是比较的足够了……
只是………………lunariss的打开速度也真有点……………… -v-b
那个画板要打开还真是困难………………
（不过这应该是服务器的问题吧？）
有可能让lunariss调用别的帖图空间（像tinypic的）的图吗？
一般的图片网上都有具体地址并且可以外连的，让程序调用，这在技术上可以实现吗？
另，某的素材太少了……找ing······
悠久ノ風 - 2005/9/30 23:01:00
没错..那个速度真的是慢得一塌糊涂
但是在找到更好的服务器之前也没什么办法..
调用别处空间的图图的话，因为最终合成还是在原先的服务器上完成，所以速度不会有任何好转..（PS：其实参数长度的限制已经决定了调用远程图片是不可能的事情..）
粘土火星 - 2005/9/30 23:19:00
建议……KFC的个人设定中有关闭这个系统显示的选项……
……此系统在网速较低时或者帖子中大量使用时会严重影响帖子下载速度
导致无法及时阅读帖子
还建议对每帖（回复）使用系统的次数进行合理限定，和会员的LV进行合理绑定，感觉每帖可使用的次数（帖动态图的数量）可以用LV /20来确定
另外，签名使用此系统也应有所限制或者可以设定……
深海蓝空 - 2005/9/30 23:25:00
以下引用粘土火星在2005-9-30 23:19:16的发言：
建议……KFC的个人设定中有关闭这个系统显示的选项……
……此系统在网速较低时或者帖子中大量使用时会严重影响帖子下载速度
导致无法及时阅读帖子
还建议对每帖（回复）使用系统的次数进行合理限定，和会员的LV进行合理绑定，感觉每帖可使用的次数（帖动态图的数量）可以用LV /20来确定
另外，签名使用此系统也应有所限制或者可以设定…… |
强烈同意，签名设限就不说了，现在回复的内容都集成在图里，图不完全刷完就不知道大家在说什么的……或者可以把尺寸再改小点，或者对话框可以选择放在上边之类的……
悠久ノ風 - 2005/9/30 23:27:00
嗯..果然此物的存在超越了当今的网络条件吗..
至于论坛这边对lunariss的限制，请与管理员大叔联系..某并不负责论坛部分的开发 - -
[STRIKE]其实发布的时候就不建议用lunariss来发贴和回复的..[/STRIKE]
粘土火星 - 2005/9/30 23:32:00
这个系统有无缓存机制？？？
碇 - 2005/9/30 23:32:00
速度确实...
莫非此物每个人浏览的时候都会重新调用函数合成一遍？
悠久ノ風 - 2005/9/30 23:35:00
所有图片都是即时生成，在服务端缓存的话实现起来会有些麻烦。
暂且使用IE的缓存吧。
PS:其实说到底还是因为KCM服务器过于泛用了..
赤松健 - 2005/9/30 23:38:00
以下引用悠久の风在2005-9-30 23:27:08的发言：
嗯..果然此物的存在超越了当今的网络条件吗.. |
[STRIKE]没有被超越的压力，哪来进步的动力？[/STRIKE]（胡话……请无视…………）
其实，可能让程序单纯的把图片重叠到一起（即：视觉上是“合成”了，但实际上仍是数幅分开的图片）吗？
就像叠起来的幻灯片？
碇 - 2005/9/30 23:39:00
IE的缓存只能保证每个人只调用一次 如果十个人看帖就要运算十次...
可以考虑在库里放张表，调用函数的时候先select，找不到再合成，并且存表...
深海蓝空 - 2005/9/30 23:40:00
其实，当初发布的时候，的确貌似是鼓励大家用这个系统作出四格漫画那样的同人作品然后专门发布的，大范围的作为回贴功能真的还不现实的说……
悠久大人不要灰心那……会找到别的适合的用法的……的确是很特别的论坛组件呢……^v^
悠久ノ風 - 2005/9/30 23:41:00
以下引用赤松健在2005-9-30 23:38:16的发言：
其实，可能让程序单纯的把图片重叠到一起（即：视觉上是“合成”了，但实际上仍是数幅分开的图片）吗？
就像叠起来的幻灯片？ |
这个的话的确是可以的，不过更多的是用到了web端的技术。大概就是在网页里建立几个层然后每层显示一张图片。
不过这个虽然减少了服务端的CPU时间却增加了很多数据传输量。
悠久ノ風 - 2005/9/30 23:44:00
以下引用碇在2005-9-30 23:39:13的发言：
IE的缓存只能保证每个人只调用一次 如果十个人看帖就要运算十次...
可以考虑在库里放张表，调用函数的时候先select，找不到再合成，并且存表... |
这样的缓存是要以牺牲空间为代价的..假设速度一旦很快了，那么就会有更多的人用这个发贴吧。而因为一个帖子的活跃期至少是一天，也就是说缓存要保留一天才有明显效果吧？那么到时候就有很多图片需要缓存..那个容量..
碇 - 2005/9/30 23:54:00
就目前情况的话总觉得缓存下会比较好
比如这一帖，把IE缓存处理掉肯定要开半天，但其实也就几张图而已，按KFC的帖量，缓存上几天也不成问题，就算一天一千张的图放缓存也占不了多少空间吧，特别有很多人把这个用在签名的，每回一帖不知道要多运算几次...还有可以考虑下判断外连，虽然不知道有没这个问题...
悠久ノ風 - 2005/10/1 0:02:00
其实..以上所有建议的措施都并不减少数据传输量的。
其实我写的图片合成代码都是很精简的了，估计也不会消耗CPU运算的大户。
可是一旦加入了什么盗链判断啊缓存机制啊，说不定这些步骤都比单纯的合成一张图耗费更多的CPU资源。
所以我感觉是服务器的带宽问题..和系统本身的设计没什么关系的。
PS:管理员大叔才增加了对话预览功能..就是说图片还没显示出来时，移动鼠标上去可以预览对话内容，暂时能解决一些问题吧。
碇 - 2005/10/1 0:24:00
数据传输量是没办法的...除非连别人的空间能彻底解决
运算量是能改善的 加入缓存机制理论上除了第一个人比现有系统多执行了一个数据库查询 和if判断数据集EOF外（似乎能忽略哪...）后面的人都只是简单的从库取值而已，直接用现有的参数作主码，数据库操作也很简单，因为查询到的只有一组记录，最多加个时间字段，放一个记时器控件每天清理过期的数据。
这个要改起来似乎不是很麻烦的，因为和原有的系统没什么关联，只要在主函数加一点代码就可以，不用在多处修改...
watashia - 2005/10/1 2:00:00
1