DXGI快速截屏录屏技术,高帧率直播桌面

介绍Windows8后推出的DesktopDuplicationAPI,通过DXGI提供高效桌面图像访问,对比GDI截屏技术,展示其高性能及低CPU占用优势。

DXGI快速截屏录屏技术

概述

  很多地方都需要用到截屏/录屏技术,比如桌面直播,桌面录制等等。在微软Windows平台,有很多截屏的接口,不过大多数性能并不理想,Windows8以后微软引入了一套新的接口,叫“Desktop Duplication API”,应用程序,可以通过这套API访问桌面数据。而由于Desktop Duplication API是通过Microsoft DirectX Graphics Infrastructure (DXGI)来提供桌面图像的,速度非常快。由于是通过GPU,所以cpu占用率很低,性能很高。

  还有一点有意思的是,Duplication API获取到的桌面数据,不管显示模式如何设置,都永远是32位RGBA数据,其实这样方便的多了,不用考虑其他可能的情况,比如24位等。

  综合来看,各方面秒杀GDI截屏技术,易用性上也比MirrorDriver技术好得多,是Windows8以后平台的截屏技术首选。

调用流程

  首先,这套接口是集成在DirextX之中的,所以更大部分DirectX接口的使用方式基本一致,也就是通过D3D,各种QueryInterface,各种Enum,核心方法,是AcquireNextFrame。先简单说下流程。

  1. 创建D3DDevice
  2. 通过一系列接口获取路径,获取到IDXGIOutputDuplication接口
  3. 调用AcquireNextFrame,获取当前桌面数据,保存在IDXGIResource中
  4. 把数据从GPU映射到内存中
  5. 拷贝需要的数据到自己的buffer里

  其中,获取到IDXGIOutputDuplication接口,是通过如下路径:
IDXGIDevice --> IDXGIAdapter --> IDXGIOutput --> IDXGIOutput1 --> IDXGIOutputDuplication

关键代码

创建接口

在这里插入图片描述

获取一帧桌面数据

在这里插入图片描述

截屏性能测试

  这里把他跟传统的使用GDI截屏技术,进行对比。程序只截取桌面数据,然后把数据保存到自己的内存buffer中,不做其他操作。CPU有点差,如果是好点的cpu,性能数据应该是更好看,不过做对比还是很明显能看出来的。

  • CPU:i3-3120M,2.5GHZ,双核四线程
  • 系统:Windows10
  • 内存:8GB

  在这里插入图片描述

我的笔记本比较老了,所以GDI最多只能跑到20帧了,不过可以看到,即使这种情况下,当不设置帧率,也就是无限循环截屏的情况下,DXGI的性能只能用可怕来形容。。。

注意:上面最后表里的DXGI帧率当时应该是统计错误,实际到达不了这么高,很多是无效采集,但是有效采集的帧率也是非常高的,具体数据等我有时间了再做统计。(2019-03-22)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

在这里插入图片描述合作请联系QQ。(转载请注明作者和出处~)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RocketMQ 中,**分片(Sharding)** 是实现高并发、高可用和可展性的重要机制之一。其核心作用是将消息的存储和消费进行分布式管理,以支持大规模消息处理场景。 ### 分片的作用 1. **提升系统吞吐量** 通过将一个 Topic 的消息分布到多个 Broker 上,每个 Broker 负责一部分消息的存储和转发,从而实现横向展,提高整体系统的吞吐能力。 2. **支持负载均衡** 在消息生产与消费过程中,分片机制使得消息可以均匀分布在多个 Broker 上,生产者和消费者可以并行地处理多个分片,实现负载均衡[^5]。 3. **增强系统可用性与容错性** 每个分片可以配置主从结构(Master-Slave),实现数据复制与故障切换,确保在某个 Broker 故障时仍能保证消息的高可用[^4]。 ### 分片的工作机制 1. **Topic 与 Message Queue 的关系** 在 RocketMQ 中,每个 Topic 会被划分为多个 **Message Queue**(也称为队列或分片),这些队列分布在不同的 Broker 上。例如,一个 Topic 可能有 4 个队列,分别分布在两个 Broker 上,每个 Broker 管理两个队列。 2. **生产者的分片选择** 当生产者发送消息时,会根据一定的策略(如轮询、哈希等)选择一个合适的 Message Queue 进行投递。这一过程称为**生产者负载均衡**。生产者会定期从 NameServer 获取 Topic 的队列分布信息,以保证选择的准确性[^5]。 3. **消费者的分片分配** 消费者组(ConsumerGroup)中的每个消费者实例会负责一部分 Message Queue 的消费任务。这一过程称为**消费者负载均衡**,由 Broker 协调完成,确保每个队列只被一个消费者实例消费,从而避免重复消费和竞争问题。 4. **消息的物理存储** RocketMQ 将所有消息写入统一的 **CommitLog** 文件中,然后通过 **ConsumeQueue** 文件记录每个 Topic 的分片索引信息,实现逻辑分片与物理存储的分离。这种机制保证了写入的高效性和读取的灵活性[^4]。 ### 分片配置与管理 - **创建 Topic 时指定分片数量** 在创建 Topic 时,可以通过命令行或配置文件指定其分片数量(即 Message Queue 数量)。 - **动态容** 可以在不中断服务的情况下,向集群中新增 Broker,并为已有 Topic 增加分片,以应对不断增长的消息量。 ### 示例代码:查看 Topic 分片信息 ```bash # 查看 Topic 的队列分布信息 mqadmin topicRoute -n localhost:9876 -t MyTopic ``` 该命令将输出 Topic `MyTopic` 的路由信息,包括各个 Message Queue 所在的 Broker 地址。 ---
评论 13
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值