xiaoxiaoling

12bet12bet怎么样 主页 新漫笔 联络 聚合 办理
  17 Posts :: 2 Stories :: 9 Comments :: 0 Trackbacks

2019年1月29日 #

将12bet怎么样搬至CSDN
posted @ 2019-01-29 10:39 clcl 阅览(25) | 谈论 (0)修正 保藏

2018年7月14日 #

ET和LT:   
   LT一般用在单线程。
   ET和EPOLLONESHOT合效果在多线程同享一个epoll环境下,EPOLLONESHOT符号触发过的事情从epoll中移除,下次有必要从头注册,用来避免多线程一同取到同一个socket的事情发作抵触。

epoll_wait 第三个参数 取事情数量:
   单线程模型当然尽或许一次多取一些功率高,多线程为了避免一个线程把一切事情取完其他线程饥饿,ACE完结是只取1个。

过错处理:
   EAGIN | EINTR | EWOULDBLOCK 重试。
   EPOLLERR | EPOLLHUP | EPOLLRDHUP 断开衔接。

惊群:
   默许体系都会有这问题,听说新体系有修正不过仍是处理一下比较好,一般处理计划是一同只需一个线程等候accept,能够独自线程accept,将衔接在分给其他作业线程。nginx是多进程模型,运用了依据同享内存的互斥锁,使得一同只需一个作业进程的epoll含有accept的socket,经过这种方法完结衔接数上的负载均衡(衔接数少的作业进程得到accept锁的概率高)。

   为了避免大数据量io时,et方法下只处理一个fd,其他fd被饿死的状况发作。linux主张能够在fd联络到的结构(一般都会自己封装一个包括fd和读写缓冲的结构体)中增加ready位,然后epoll_wait触发事情之后仅将其置位为ready方法,然后在下边轮询ready fd列表。


epoll完结:  
   epoll内部用了一个红黑树记载增加的socket,用了一个双向链表接纳内核触发的事情。

   注册的事情挂载在红黑树中(红黑树的刺进时刻功率是logN,其间n为树的高度)。

   挂载的事情会与设备(网卡)驱动树立回调联系,也便是说,当相应的事情发作时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发作的事情增加到rdlist双链表中。

   运用mmap映射内存,削减内核态和用户态的不同内存地址空间仿制开支。每次注册新的事情到epoll中时,会把fd仿制进内核,经过内核于用户空间mmap同一块内存确保了只会仿制一次。(回来的时分不需求仿制,select要)

   履行epoll_ctl时,除了把socket放到红黑树上,还会给内核间断处理程序注册一个回调函数,告知内核,假如这个句柄的间断到了,就把它放到准备安排妥当list链表里。所以,当一个socket上有数据到了,内核在把网卡上的数据copy到内核中后就把socket刺进到准备安排妥当链表里了。链表又是经过mmap映射的空间,所以在传递给用户程序的时分不需求仿制(这也是为什么比select功率高的原因,epoll_wait回来的仅仅安排妥当行列,不需求轮询 不需求仿制完结的事情列表,select,poll完结需求自己不断轮询一切fd调集,直到设备安排妥当)。

   epoll_wait最终会查看socket,假如是 LT,并且这些socket上的确有未处理的事情时,又把该句柄放回到刚刚清空的准备安排妥当链表了(LT比ET低效的原因)。

 

可见,假如没有许多的闲暇,无效衔接,epoll功率不比select高。

测验数据(仅是刚触摸go的时分猎奇做的参阅含义的测验):  

   相同的环境,echo服务器测并发io,单线程epoll qps:45000左右,每衔接/协程 go: 50000多,多线程epoll(开6个epoll,每个epoll开8线程,总共48线程):qps 70000多。

 


posted @ 2018-07-14 11:17 clcl 阅览(91) | 谈论 (0)修正 保藏

2018年7月13日 #

概念
   tcp和udp,衔接和无衔接都是协议,是同享物理介质的传输数据的运用程序之间的约好。面向衔接的协议保护了segment的状况和次第。

毛病 :
      默许无keep alive:
m88 188bet uedbet 威廉希尔 明升 bwin 明升88 bodog bwin 明升m88.com 18luck 188bet unibet unibet Ladbrokes Ladbrokes casino m88明升 明升 明升 m88.com 188bet m88 明陞 uedbet赫塔菲官网 365bet官网 m88 help
拔网线或路由器溃散:发送端超时(重传12次大约9分钟)后抛弃,接纳端读errorno ETIMEOUT,假如没有读则要比及下一次写失利sigpipe。假如中心路由器无法转发则向源端发送 ICMP 方针主机不可达。
程序退出(包括溃散): 程序退出和正常调用 close无法差异,都会回来FIN表明退出,假如一端退出,
      另一端: 1.第一次写合法(接纳到fin后仍是能持续发送数据)第2次写的时分发现衔接不存在,得到 RST RESET过错 2.读的时分得到 conn reset过错,持续写则被SIGPIPE信号间断,程序退出。
主机宕机: 宕机后无法经过FIN告诉对方,对方会持续重传直到timeout。假如超时前宕机的主机重启了,此刻收到重传的主机没有衔接记载,向源回来rst,发送端得到ECONNRESET过错,假如发送端在读得到 conn reset过错,持续写则被SIGPIPE信号间断,程序退出。
敞开keep alive状况下:
假如程序溃散回来fin , 假如主机可达但程序不存在(主机重启),则呼应RSt,源端得到ECONNRESET 过错。
假如对方没有对keep alive呼应ACK 或许RST,源端TIMEOUT(重试9次,每次距离75秒,守时器2小时超时后的11.25分钟)以程序自己做心跳仍是必要的。

细节
tcp写操作:
用户态仿制到内核态写缓冲区后回来,只回来显着过错:socket无效或缓冲区无效。影响的要素有:发送窗口,拥塞窗口,写缓冲区巨细,Nagle。
tcp是进步带宽运用率的协议,每次发送倾向mss巨细,一同不能大于对端指定的巨细(发送窗口),tcp只考虑了网络中路由器缓冲区耗尽状况(也是tcp的约束)所以有拥塞窗口和慢发动:为了避免网络拥塞(自律的协议)每次发送的不能大于对方指定的(发送窗口)和自己给自己约束的(拥塞窗口)。


    

慢发动:一开端指数级的增加拥塞窗口,到一个门阀值后变成线性的, 之后每次超时都把门阀值下降到本来一半(并且rto翻倍,TCP超时核算是RTOx2,这样接连丢三次包就变成RTOx8了,非常恐惧),拥塞窗口设置为1从头开端慢发动(指数级增加)。一切都是为了让路由器有时刻处理积压的缓冲。(所以不适用于频频断开衔接的移动网络,这也是为什么曾经的下载工具开多条tcp传输速度更快的原因)。

Nagle算法:第一次(此刻没有等候ack承认,闲暇衔接)发送小包成功,第2次持续发送 :哪怕发送窗口,拥塞窗口都很大,之前的包没有ack承认仍旧不让发直到收到之前的 ack承认。

shutdown和close的差异:

close仅仅递减引证计数, shutdown的半关完毕会议影响一切的进程。

shutdown how=0 封闭读,读会回来eof
shutdown how=1 封闭写,任何写会犯错,将缓冲区的发送完后会发送fin表明没有数据了,
收到对方发送的fin,recv会回来0。
listen 的第二个参数拟定的是全衔接行列巨细(accept)

time_wait和close_wait
time_wait 呈现在自动close方,为了避免新衔接纳到旧链接的数据包, 数量高能够经过设置内核参数缩短时刻下降数值(2msl)。能够经过 SO_LINGER封闭。
close_wait 呈现在被迫close方,数量高一般由于功用或许bug在收到fin后没有调用close。

SO_REUSEADDR
用于程序溃散后重启,处理地址被占用问题(time_wait),另一个用处是开两个服务,第一个拟定地址,第二个指定INADDR_ANY 通配地址,假如客户端衔接的是拟定地址相同会到第一个socket上。
      关于绑定于同一地址端口组合上的UDP socket,kernel测验在它们之间均匀分配收到的数据包;关于绑定于同一地址端口组合上的TCP监听socket,kernel测验在它们之间均匀分配收到的衔接恳求(调用accept()方法所得到的恳求)。

Nagle和推迟ack的问题:
发送端数据未发送完,被nagle制止发送(有必要等候接纳端的ack,也便是没有未承认的包才答应发送),此刻接纳端ack被推迟发送(希望将ack和数据一同发送进步带宽运用率)而发送方数据未发送完导致接纳端无法回复,两边死锁。
已衔接的UDP:
tcp的connect是开端三次握手,将长途的ip端口绑定到socket,而bind是绑定本地的ip端口。
udp没有三次握手,connect纯粹是本地行为,将长途的ip端口绑定到socket上。
已衔接的udp能够不必sendto,sendto会先将socket和意图地址衔接,然后发送数据后再断开,罢了衔接的现已绑定地址能够用write,进步功率(材料显现暂时衔接断开所用的时刻是传输udp数据的三分之一,仍是很可观的)。异步过错的接纳,运用sendto发送完体系就没有记载了,运用程序无法接纳之后icmp回来的过错。
接纳端已衔接udp的优点: 能够标识哪个socket是哪个用户,其他还能够独占衔接,再另一个当地调用recvfrom指定相同地址会回来ECONNREFUSED,由于此衔接现已被绑定。
posted @ 2018-07-13 15:49 clcl 阅览(71) | 谈论 (0)修正 保藏

2018年5月9日 #

   作业上尽管和cdn没联系可是技能方向仍是许多相似之处的,例如:负载均衡,缓存,分布式,路由等。
   cdn简略的说便是个杂乱的大缓存,由于方针用户(包括源和端)广泛直接导致了其杂乱性,遍及广节点多则需求分流负载乃至自组织,运用冗杂则需求分流路由,提速则需求缓存,安稳则需求监控调度,为了通明则需求各种映射。
   由于接入面广和网络的杂乱性,不或许让客户端直接面临源,所以就有了专门接入客户端的边际服务器/组,这些边际服务器和后端的调度,监控,源服务器通讯。既然是缓存就涉及到数据一致性的问题,最简略的便是各接入端的边际服务器在需求的时分到后台拉取,或许更智能的他们之间能够彼此拉取,乃至后台调度提早推送。
   边际接纳到恳求后首战之地的问题便是对恳求的内容 “去哪找”和“怎样去”,想要知道内容的方位,一般缓存的完结不外乎便是一致到一个目录服务器找,或许播送一切自己知道的节点问一圈,更高效的方法是将恳求url哈希后直接找到意图地址,当然只需是缓存都会过期也就有TTL的概念。“怎样去”的方法多种多样,由于互联网web服务居多依据DNS的路由运用最广泛,缺陷是客户端和中继点会缓存,更新需求必守时刻。HTTP重定向,URL改写,也有直接在网络设备路由器上做,直接在路由表中坚持途径。这些方法在cdn这个杂乱的体系中依据需求运用,例如边际服务器为了接纳到客户端的恳求能够运用dns重定向,然后再用哈希或许url改写转发到后端的源。 
   现如今的网络内容有许多是动态生成的,对这些无法提早缓存的内容能够直接略过只存静态内容(分段缓存),拼装的时分发送回客户端或许直接赋予边际服务器生成动态内容的才能(边际核算)当然这对网页的制造有标准。
   面向群众的服务都有潮汐效应,在热门时段的拜访量是平常的几十上百倍(依据二八理论,80%的问题都是在20%的当地呈现的,热门拜访量也是大多拜访小部分数据,假如能提早将热门缓存于各边际服务器最直接有用),假如有自适应的动态调整功用整个服务会强健许多。边际服务器是离用户最近的,能够将每个节点看成组,组长监控负载自适应的增加删去组员(缓存服务器)以及更新dns,不答应组员跨组拉数据。当然假如客户端之间能够运用P2P彼此取数据也是一个方法。   
   当时呈现了依据流媒体的cdn,视频内容分发在后端以文件的方法传输(合适传输的格局更高效),到边际服务器再以流的方法和客户端传输(不需求悉数传完即可开端播映)。一同也要归纳考虑时段需求,视频编码战略也很重要。
posted @ 2018-05-09 23:57 clcl 阅览(41) | 谈论 (0)修正 保藏

2017年2月5日 #


dpdk是经过许多不同的纬度来加快包处理的,其间首要包括:

 

hugepage大页内存(进程运用的是虚拟地址,一般页表(4k)能映射的虚拟地址空间有限,运用大页能削减换页次数进步cache射中,经过mmap把大页映射到用户态的虚拟地址空间有用过mmap的都知道这是完结同享内存的手法,所以dpdk还支撑多进程同享内存)

 

cache预取 (每次预读当时数据相邻前后的数据),批量操作数据,cache line对齐(经过糟蹋一点内存即将操作的数据对齐)

 

接纳了网卡用户态驱动运用轮询而不是网卡间断

 

将网卡rx tx行列映射到用户态空间完结真实的零仿制(传统仓库至少也得一次仿制,由于行列空间在内核而内核和用户态运用不同的地址空间)(传统仓库为了支撑通用性,例如ipx等其他网络,将包处理进程分了许多层次,层之间的接口标准一致数据结构就需求转化,无形中带来了巨大的本钱,如osi七层模型而有用的便是tcp/ip四层模型)

 

线程绑定cpu

 

支撑NUMA,不同的core归于不同的node,每个node有自己的mempool削减抵触

 

无锁环形行列(抵触发作时也是一次cas的开支)

 

dpdk经过tools/dpdk-setup.sh的脚本,经过编译、挂载内核模块, 绑定网卡(先把网卡ifconfig down),设置hugepage后就能够运用了。

 

 

在内核模块igb加载时,会注册pci设备驱动

static struct pci_driver igbuio_pci_driver = {

.name = "igb_uio",

.id_table = NULL,

.probe = igbuio_pci_probe,

.remove = igbuio_pci_remove,

};

 

在绑定网卡时,会调用igbuio_pci_probe,运用用户态驱动uio接纳网卡(间断处理、mmap映射设备内存到用户空间)

体系发动时,bios会将设备总线地址信息记载在/sys/bus/pci/devices,dpdk程序发动时会去这儿扫描pci设备,依据不同类型的NIC有对应的初始化流程。在后边装备行列的时分会把用户态的行列内存地址经过硬件指令交给NIC,然后完结零仿制。


 

假如NIC收到包,会做符号,轮询的时分经过符号取数据包

while (nb_rx < nb_pkts) {

/*

 * The order of operations here is important as the DD status

 * bit must not be read after any other descriptor fields.

 * rx_ring and rxdp are pointing to volatile data so the order

 * of accesses cannot be reordered by the compiler. If they were

 * not volatile, they could be reordered which could lead to

 * using invalid descriptor fields when read from rxd.

 */

rxdp = &rx_ring[rx_id];

staterr = rxdp->wb.upper.status_error;

if (! (staterr & rte_cpu_to_le_32(E1000_RXD_STAT_DD)))

break;

rxd = *rxdp;

发包的轮询便是轮询发包完毕的硬件标志位,硬件发包完结会写回标志位,驱动发现后再开释对应的描述符和缓冲块。

 

KNI

经过创立一个虚拟网卡,将收到的包丢给协议栈

 /* 发送skb到协议栈 */

            /* Call netif interface */

            netif_receive_skb(skb);

 

POWER

在负载小的时分没有必要运用轮询方法,这时能够翻开网卡间断 运用eventfd  epoll告诉用户层

 

Ring

无锁环形行列的中心便是操作头尾索引,先将头尾索引赋给暂时变量,再把尾索引往后跳n个方位,运用cas判断头假如仍是在本来的方位就指向尾不然就重复这个进程,然后在操作中心越过的n个元素便是安全的了,此刻头尾索引应该指向同一个方位,假如不同应该是有其他线程也在操作,重复等候即可。(这儿有个细节,索引是只加不减的,由于是环形行列索引又是unsigned 32bits,所以每次取数据前把索引模行列长度-1, uint32_t mask;           /**< Mask (size-1) of ring. */即可)

 

Windows下运用vmware虚拟机的时分呈现EAL: Error reading from file descriptor,依据网上的说法打了patch仍是不可,后来测验挂载内核模块的时分不加载vfio模块就能够了

 

posted @ 188bet centre clcl 阅览(366) | 谈论 (0)修正 保藏

2017年1月24日 #

Redis是作业中很常用的,这儿将比较遍及运用的结构研讨了下做个备忘。

 

hash

完结和dnspod的dataset不相上下,实质上是个二维数组,经过将key哈希作为一维的下表,第二维的数组存相同哈希的元素,查找运用遍历的方法,所以这儿redis做了优化,当满意条件的时分(数组数量太大)会进行rehash,动态扩展桶的数量来削减最终一维遍历的次数.

函数称号

效果

杂乱度

dictCreate

创立一个新字典

O(1)

dictResize

从头规划字典的巨细

O(1)

dictExpand

扩展字典

O(1)

dictRehash

对字典进行N步渐进式Rehash

O(N)

_dictRehashStep

对字典进行1步测验Rehash

O(N)

dictAdd

增加一个元素

O(1)

dictReplace

替换给定key的value值

O(1)

dictDelete

删去一个元素

O(N)

dictRelease

开释字典

O(1)

dictFind

查找一个元素

O(N)

dictFetchValue

经过key查找value

O(N)

dictGetRandomKey

随机回来字典中一个元素

O(1)

 

字典结构

typedef struct dict {

    // 类型特定函数

    dictType *type;

    // 私有数据

    void *privdata;

    // 哈希表

    dictht ht[2];

    // rehash 索引

    // 当 rehash 不在进行时,值为 -1

    int rehashidx; /* rehashing not in progress if rehashidx == -1 */

    // 现在正在运转的安全迭代器的数量

    int iterators; /* number of iterators currently running */

} dict;

这儿哈希表有两个,一般都用ht[0],当需求rehash的时分会创立一个比ht[0]大的 2 的 N 次方的ht[1],然后渐进式的将数据dictEntry移过去(除了守时的rehash,在每次操作哈希表时都会_dictRehashStep),完结后将ht[1]替换ht[0]

 

zset

zset实质便是list,只不过每个元素都有若干个指向后继span长的指针,这样简略的规划大大进步了功率,使得能够比较平衡二叉树,查找、删去、刺进等操作都能够在对数希望时刻内完结,比照平衡树,跳动表的完结要简略直观许多。

 

 

/* ZSETs use a specialized version of Skiplists */

/*

 * 跳动表节点

 */

typedef struct zskiplistNode {

    // 成员目标

    robj *obj;

    // 分值

    double score;

    // 撤退指针

    struct zskiplistNode *backward;

    // 层

    struct zskiplistLevel {

        // 行进指针

        struct zskiplistNode *forward;

        // 跨度

        unsigned int span;

    } level[];

} zskiplistNode;

 

/*

 * 跳动表

 */

typedef struct zskiplist {

    // 表头节点和表尾节点

    struct zskiplistNode *header, *tail;

    // 表中节点的数量

    unsigned long length;

    // 表中层数最大的节点的层数

    int level;

} zskiplist;

 

/*

 * 有序调集

 */

typedef struct zset {

 

    // 字典,键为成员,值为分值

    // 用于支撑 O(1) 杂乱度的按成员取分值操作

    dict *dict;

    // 跳动表,按分值排序成员

    // 用于支撑均匀杂乱度为 O(log N) 的按分值定位成员操作

    // 以及规模操作

    zskiplist *zsl;

 

} zset;

 

尽管这种方法排序查找很快,可是修正的话就得多做些作业了

 

/* Delete an element with matching score/object from the skiplist.

 *

 * 从跳动表 zsl 中删去包括给定节点 score 并且带有指定目标 obj 的节点。

 *

 * T_wrost = O(N^2), T_avg = O(N log N)

 */

int zslDelete(zskiplist *zsl, double score, robj *obj)

 

intset

typedef struct intset {  

uint32_t encoding; //所运用类型的长度,4\8\16  

uint32_t length; //元素个数  

int8_t contents[]; //保存元素的数组  

} intset;  

 

intset其实便是数组,有序、无重复地保存多个整数值,查找用的是二分查找 * T = O(log N),增加的话在找到对应的数组中应该存在的位子后运用memmove向后移出空位添补(当然需求先realloc预分配空间),同理删去也是用memmove向前移动

 

set

当运用整数时,运用intset,不然运用哈希表

 

 

其他的关于网络事情处理,epoll,回调,拆包都和正常运用差不多,关于过错处理EINTR(体系调用期间发作间断)和EAGAIN 持续重试而假如是EPOLLHUP或EPOLLERR则让io该读读该写写,有错处理便是了。

 

 

posted @ 2017-01-24 18:13 clcl 阅览(93) | 谈论 (0)修正 保藏

2017年1月23日 #

 

 

dns的递归解析进程仍是挺繁琐的,要知道一个域名或许有cname、ns 而恳求的cname、ns或许还有cname、ns,假如依照线性的处理每个恳求那逻辑就变成毛线团了

dnspod的处理仍是挺奇妙的,经过一个公共的数据集dataset将一切域名对应的a、cname、ns等类型的数据作为独自的条目存入,当有需求某个域名的信息时先去dataset找,找不到在参加qlist恳求根,有专门的线程不间断的将qlist轮询dataset找(这儿只需次数答应,没得到想要的成果就轮询一切qlist到dataset找尽管能够简化逻辑别离的完全可是会是个功用瓶颈,后边有计划)当根回来今后仅仅简略的将记载(通常是一个域名的cname、ns或许a)存入dataset(而不是持续流程,由于依据这个回来是cname仍是ns或许a处理不同逻辑杂乱,而这样处理关于用到相同域名的恳求还有优化效果),剩余的作业交给那儿不间断轮询的线程

 

Dnspod首要由3个run(若干个线程)组成

 

run_sentinel  监听53端口接纳客户端恳求,将恳求放到行列中

run_fetcher   从行列中取出恳求,依据qname获得最终一级cname,查看本地dataset 是否有记载,假如有则回来,没有则将该恳求放入qlist中

 

run_quizzer    

1.不间断的遍历qlist,只需状况为PROCESS_QUERYdataset中没有的就向对应的根发送恳求。

2.经过epoll等候根回来,解析回来的数据参加 dataset

3.查看记载的ttl,在将记载参加dataset时还会将这些记载以红黑树的方法组织起来,获得ttl最早到期的,将其放入qlist中等候改写,留意这儿不是删去,假如收不到不回来则该记载一向存在

 

关于dataset的完结

dataset是运用哈希表完结的,实质上是个二维数组,将域名哈希成一个值,模上数组的数量作为下标,找到对应的数组接着遍历查找,依据需求能够扩展数组的数量进步功用。

 

咱们的优化手法

之前说到dnspod的qlist会不间断轮询,归于自动查询,对功用有不小的影响,这儿咱们采纳的做法是被迫(相似回调的方法),咱们将恳求的域名和类型分类,相同的放在一组,当dataset找不到向根宣布恳求后咱们并不每次自动轮询,而是在比及应对后,触发该域名和类型的恳求组,让他们依据自己的逻辑走下一步(一般是先找该域名的最终一级cname,依据这个cname查是否存在他的对应恳求类型的记载,一般是a或许ns,假如没有,则找这个cname的ns)

 

以上能够看出dataset很重要,负载也不小,还常常需求并发拜访,这儿咱们每次接纳到根的回复后,除了将记载的答案加进dataset,还创立一个暂时的dataset,只存该次回复的信息,在后边的流程会优先到这儿去找,没有的再找dataset。

posted @ 2017-01-23 15:14 clcl 阅览(72) | 谈论 (0)修正 保藏

2017年1月22日 #

     摘要: 最近在研讨DPDK,这是sigcomm 2014的论文,纪录在此备忘Ps:  文中关键词的概念:segment : 对应于tcp的PDU(协议传输单元),这儿应该指tcp层的包,假如一个包太大tcp担任将它拆分红多个segment(这个概念对了解后文有协助)依据unix网络编程卷1 第8页注解2:packet是IP层传递给链路层并且由链路层打包好封装在帧中的数据(不包括帧头)而IP层的包...  阅览全文
posted @ 2017-01-22 18:01 clcl 阅览(264) | 谈论 (0)修正 保藏

2010年4月27日 #

一向想用cegui,可是没机会用,仅仅抽暇看其代码

最近听朋友说0.7 debug下帧数进步100多,挺惊奇的,从头到久别了的官网上下了0.7.1

看了下烘托的完结(GL)

首要,增加了GeometryBuffer玩意,使得每个window保存了归于自己的极点和纹路信息

然后在RenderingSurface中有GeometryBuffer行列,使得每个具有AutoRenderingSurface特点的window有归于自己的行列(默许只需FrameWindow才有)

而在drawself中履行的则是先经过looknfeel,把需求烘托的信息丢到每个部件自己的GeometryBuffer里,然后把GeometryBuffer丢到RenderingSurface的行列中(一般为

FrameWindow的GeometryBuffer行列,每个面板就有自己的烘托行列了)

要知道以往都是只需一个行列的,要烘托啥直接往里塞。 。 。
这样一改就不必每个小部件有更改都要悉数从头清空烘托了


再往后便是把每个窗口行列里的GeometryBuffer烘托到各自的RenderingSurface表面上,这儿要留意的是并不是烘托到屏幕上而是表面上,cegui在这儿运用了烘托到纹路,GL

用的是fbo完结的。

留意RenderingSurface只需两个来历,一是经过设置AutoRenderingSurface特点,另一个便是RenderingRoot了,RenderingRoot只需一个,在render中,经过第一个来历的使

用的是fbo的烘托,而第二个来历则直接烘托到屏幕了。

一切的这些履行完后就能够烘托到屏幕了,经过RenderingRoot履行,留意这儿的RenderingRoot中的RenderTarget和之前的不相同,这儿用的是OpenGLViewportTarget而不是

OpenGLFBOTextureTarget。

posted @ 2010-04-27 20:56 clcl 阅览(985) | 谈论 (2)修正 保藏

2009年10月25日 #

     摘要: 这个看代码里边batch相关的。[Direct3D] 完结批次烘托、硬件 T&L 的烘托器和 D3DPipeline 在是否从 D3DRender 供给极点缓存区操作给流水线时做了一些权衡,最终决议暂时运用 IDirect3DDevice9::DrawPrimitiveUP 来烘托,由于它更简单书写,并且开支是一次极点仿制,流水线也不必操心对缓存的运用。 (DrawPrimitive的...  阅览全文
posted @ 2009-10-25 17:15 clcl 阅览(944) | 谈论 (0)修正 保藏

仅列出标题  下一页