Symbian屏幕双缓冲和DSA

DSA全分辨率 善领DSA全分辨率版本,兼容各种分辨率,试用各种后视镜,搜星快 立即下载

参考网上一篇文章重新整理了下屏幕双缓冲和DSA的知识!

⑴图形设置和图形上下文

       应用程序绘制图形时,必须要使用图形设备和图形上下文。

       图形设备是绘制操作的对象(如屏幕、打印机等),图形设备上下文提供了一种设备的抽象机制从而完全屏蔽了具体的图形设备,应用程序在使用这些图形设备时只需要和这些抽象的图形设备类交互即可,而不必考虑其具体的设备。

       图形上下文是绘画平台及绘画所需要工具的集合体,它还包括平台的尺寸、方向、颜色和所有能实现绘画想象力的附件。

       下面为Symbian中使用的图形设备及其功能,它们是实现绘画的基础。

图形设备描述
CGraphicsDevice图形设备的基类
CBitmapDevice位图化图形设备的基类
CFbsDevice使用字体位图服务器的图形设备基类
CPrinterDevice具有打印功能的设备基类
CWsScreenDevice使用窗口服务器的屏幕设备
CFbsBitmapDevice使用字体位图服务器的设备具体实现
CFbsScreenDevice使用直接屏幕访问(DSA),而不通过窗口服务器

      这些设备类的继承关系如下:  

 

   CWindowsGc用于屏幕绘制,CFbsBitGc则用于内存绘制!

⑵双缓冲

      应用程序在屏幕上的描画一般是使用CWsScreenDevice图形设备来完成,与CWindowGc图形上下文相关联。CONE提供了一个 CWindowGc实例作为描画控件的标准图形上下文。它被CCoeEnv创建并且可以使用CCoeControls::SystemGc()方法访问。 CWindowGc的描画方法在客户端窗口服务器缓冲区上进行缓冲。

      

void CExampleControl::Draw( const TRect& /*aRect*/ ) const
{
 // Get the system graphics context
 CWindowGc& gc = SystemGc();
 // Set drawing settings
 gc.SetBrushStyle( CGraphicsContext::ESolidBrush );
 gc.SetBrushColor( KRgbRed );
 // Draw
 gc.DrawLine( TPoint(10,10), TPoint(30,10) );
} 

        DrawNow()强制控件立即重画自己,而DrawDeferred()导致一个重画事件使用低优先级操作!

         如果一个游戏的图形由多个需要被经常更新的运动对象组成,窗口服务器的客户端缓冲可能被充满并且可能会在所有对象都更新的时候溢出,用户可能会发现屏幕出现闪烁。如果一个视图仍然在更新的时候,可能会出现闪烁或者其他不希望的效果。这些问题的解决方案是双缓冲,图形先被画在一个屏外位图上,然后被画到屏幕上作为一个单一窗口服务器操作。尤其是对于那种在一秒钟内重画几次屏幕的游戏,使用屏外位图可以改善它们的性能。

 

  一个屏外位图可以使用位图化的图形上下文和图形设备类来创建:CFbsBitGc和CFbsBitmapDevice。它们使用其他的上下文和设备类来创建和使用。为了获得额外的性能,位图自己就应该是一个CWsBitmap位图。在屏外位图更新之后,它可以使用正常的窗口服务器的描画方法画在窗口中。

  当一个应用程序在一个窗口画位图时,它转化为和窗口相同的显示模式。这是一个很消耗时间的操作,实质上可能降低描画的速度。因此把位图用于动画的游戏应该在动画开始之前就完成转化。转化可以通过使用一个屏外位图来执行,如下面的示例方法演示:

CFbsBitmap* CExampleControl::LoadAndConvertBitmapL( Const TDesC& aFileName, TInt aBitmapId )
{
 // Load the bitmap
 CFbsBitmap* originalBitmap = new ( ELeave ) CFbsBitmap();
 CleanupStack::PushL( originalBitmap );
 User::LeaveIfError( originalBitmap->Load( aFileName, aBitmapId, EFalse ) );


 // Create a new bitmap, graphics device and context
 CFbsBitmap* newBitmap = new ( ELeave ) CFbsBitmap();
 CleanupStack::PushL( newBitmap );
 newBitmap->Create( originalBitmap->SizeInPixels(), Window()->DisplayMode() );
 CFbsBitmapDevice* graphicsDevice = CFbsBitmapDevice::NewL(newBitmap);
 CleanupStack::PushL( graphicsDevice );
 CFbsBitGc* graphicsContext;
 User::LeaveIfError( graphicsDevice->CreateContext( graphicsContext ) );
 TPoint zero(0,0);

 // Blit the loaded bitmap to the new bitmap
 graphicsContext->BitBlt( zero, originalBitmap );
 CleanupStack::Pop(3);
 delete graphicsContext;
 delete graphicsDevice ;
 delete originalBitmap;
 return newBitmap;
} 

  示例方法使用一个文件名和位图ID作为参数,并且从一个MBM文件中装载相应的位图。如果一个游戏有许多位图应该转化,那么应该在游戏或者等级的初始化阶段转化,因此用户就不会看到这个操作了。

⑵直接屏幕访问(DSA)

  使用窗口服务器在屏幕上描画需要一个上下文转换,这会减慢描画速度。为了绕过窗口服务器省去繁琐的上下文转换,可以直接访问屏幕。这被称作直接屏幕访问。

        在Symbian OS中有两种方法来直接在屏幕上描画:

  ①CFbsScreenDevice是一个可以被发送到屏幕驱动程序SCDV.DLL的图形设备。在创建一个CFbsBitGc图形上下文之后,它能像任何其他的图形设备一样使用。然而,可以直接在屏幕上描画,而不需要使用窗口服务器。

        ②直接在屏幕上描画的另一种方法是从系统中查询屏幕内存地址,这可以使用UserSrv类来实现:

TPckgBuf<TScreenInfoV01> infoPckg;
TScreenInfoV01& screenInfo = infoPckg();
UserSvr::ScreenInfo(infoPckg);
TUint16* screenMemory = screenInfo.iScreenAddress + 16;
  屏幕内存有一个32字节的头。

  即使在屏幕内存内写数据比CFbsScreenDevice稍微快一点,但是功能可能根据硬件和屏幕的设备驱动程序的不同而有差异。在一些基于Symbian OS的终端中,屏幕在内存变化的时候自动从屏幕内存中更新,而在其他的终端中描画需要明确的激活。屏幕内存地址只对目标硬件有效,因此描画代码需要分为硬件和模拟器两部分。在模拟器环境中,可以描画到一个屏外位图中,而不是屏幕内存中,然后使用正常的窗口服务器描画方法位块传送到屏幕上。环境可以通过使用__WINS__定义来检测出来。

#ifdef __WINS__ // Emulator environment
// Draw to an off-screen bitmap
#else // Hardware environment
// Draw directly to the screen memory
#endif 

  这两种直接描画方法的一个共同的问题是窗口服务器不了解描画,因此它不能通知应用程序是否出现另一个窗口或者窗口组。 即使当应用程序失去焦点的时候得到一个事件,它们也不能停止直接描画,因为直接描画实在太快了,并且屏幕内容有可能被弄乱。 这可能发生在玩游戏的时候,突然有电话打进来的情况下。

 
        新近的GT 6.1版本提供了一个应用编程接口用于直接描画,将能解决前面提到的问题。

        这个应用编程接口由两个类组成:一个MDirectScreenAccess类,提供用于应用程序的回调方法,还有一个CDirectScreenAccess类处理与窗口服务器的通讯。 下面的代码说明CDirectScreenAccess实例是如何构造的,以及直接描画支持是如何激活的。

iDrawer = CDirectScreenAccess::NewL(iEikonEnv->WsSession(), *iEikonEnv->ScreenDevice(), Window(), *this);
iEikonEnv->WsSession().Flush();
iDrawer->StartL();
iDrawer->ScreenDevice()->SetAutoUpdate(ETrue); 

  CDirectScreenAccess的NewL方法获得一个窗口服务器会话、CONE的图形设备、应用程序窗口和一个到MDirectedScreenAccess导出类的指针作为参数。 在CDirectScreenAccess::StartL被调用来激活直接描画支持之前,客户端窗口服务器缓冲应该溢出。 为了能自动更新屏幕,屏幕设备的SetAutoUpdate方法需要使用ETrue参数,否则gc draw指令不会在模拟器中立即显示,而是在下一次冲刷(Flush)视窗服务器时才显示。 当直接描画支持激活的时候,CDirectScreenAccess产生一个CFbsBitGc图形上下文,可以被应用程序用来在屏幕上绘画。

iDrawer->Gc()->BitBlt( TPoint(0,0), iBitmap ); 

  当另一个窗口出现在应用程序窗口上时,CDirectScreenAccess从窗口服务器取得一个事件来中断描画。 CDirectScreenAccess然后调用MDirectScreenAccess派生类的AbortNow方法,这个方法必须被应用程序重载以便中断描画。 为了防止屏幕被弄乱,窗口服务器直到中断描画事件被处理的时候才画重叠窗口。


 

 转载自:http://blog.youkuaiyun.com/dongfengsun/archive/2007/04/09/1557141.aspx
【OpenClaw从入门到精通】第41篇:2026年4月最新版——从零开始搭建你的第一个安全AI助理(保姆级实战教程) 2026年3月CNCERT联合发布《OpenClaw安全使用实践指南》后,安全部署成为OpenClaw使用的核心前提。本文针对新手及进阶用户,基于官方安全指引,提供三套实战部署方案:阿里云一键部署(新手首选)、Docker容器隔离部署(进阶推荐)、本地安全安装(测试专用),并详解阿里云百炼Coding Plan API接入流程。全文涵盖环境准备、分步实操、安全加固、问题排查等全流程,所有命令可直接复制执行,无需依赖外部代码库。通过本文,读者可零基础搭建安全隔离的OpenClaw AI助理,兼顾实用性与安全性 阅读详情

相关推荐

解密高并发系统的瓶颈:五大解决方案

在互联网应用中,高并发是指在短时间内同时有大量的用户访问一个网站或服务,造成系统压力过大,导致服务器宕机或服务停止响应的情况。高并发是互联网应用面临的一个重要问题,需要采取一系列措施来解决。负载均衡、缓存、数据库优化、异步处理和分布式架构是解决高并发问题的主要方法。在实际应用中,需要根据具体情况选择不同的方法来解决高并发问题。在高并发情况下,使用负载均衡是解决问题的一种常见方法。负载均衡可以通过将请求分配到多个服务器上,从而减少单个服务器的负载。这可以通过硬件设备或软件实现。

BUG制造者:图图 <p>这是一个P标签</p> 3901

Symbian屏幕双缓冲&&DSA

参考网上一篇文章重新整理了下屏幕双缓冲和DSA的知识!⑴图形设置和图形上下文       应用程序绘制图形时,必须要使用图形设备和图形上下文。       图形设备是绘制操作的对象(如屏幕、打印机等),图形设备上下文提供了一种设备的抽象机制从而完全屏蔽了具体的图形设备,应用程序在使用这些图形设备时只需要和这些抽象的图形设备类交互即可,而不必考虑其具体的设备。       图形上下文

大道至简 2904

同步辐射材料科学应用指南:从XAFS原位实验到数据处理

材料结构分析是材料研究的核心环节,但传统实验室X射线受限于能量固定、亮度不足,往往难以回答原子局域配位、非晶结构及动态演变等关键问题。同步辐射光源以高通量、连续可调、偏振可控及脉冲时间结构等特性,将材料表征从静态观察推进到原位动态追踪层次。基于X射线吸收精细结构谱(XAFS)、原位实验、X射线衍射与散射、微区成像等技术,研究人员可实现元素选择性分析、近邻原子环境解析及真实工况下的结构演变监测。本文从技术原理出发,覆盖实验方案设计、样品制备、现场对光、数据处理与常见故障排查,并结合典型应用场景,为材料科学领域

weixin_32612263的博客 155

Java游戏编程不完全详解-2

三种Java游戏类型 使用Java我们可以创建三种类型的游戏:applet游戏,窗体游戏和全屏幕游戏。 applet游戏—是运行在浏览器中的应用。它的好处理用户不需要安装应用。但是用户必须安装JRE并且必须在web浏览器中运行。另外,applet小程序还有安全限制,以保证它不恶意破坏本地代码。比如applet程序不能把游戏保存到用户机的硬盘中去。它只能通过网络连接一个服务器 窗体游戏—该类型的游戏没有applet流程的安全限制,它与普通的应用一样,有标量栏、关闭按钮等。但是它不吸收用户,特别是当我们沉浸在

weixin_56659504的博客 727

给新考上北大软件与微电子学院的同学——利用北大资源

利用北大资源 首先,恭喜大家考入北京大学!希望软院成为各位人生旅途中快乐的一站! 说明:限于本人搜集能力有限,本文只列出本人常利用的资源(上课老师会告知的资源也不在此列),本文所述的资源只是北大可利用资源的一个子集。 一、 图书馆资源:北京大学图书馆的资源数量,我就不多废话了,这里主要说一样怎样利用这些资源。 a) 传统资源分布及查找:这种资源主要包括纸质书箱、杂志、光盘等内...

Felomeng的技术博客 1万+

深入解析docx4j:从Word到PDF的高保真转换实战

本文深入解析了如何使用纯Java开源库docx4j实现Word到PDF的高保真转换。针对中文环境,重点讲解了字体映射原理、Linux服务器字体部署方案,并提供了完整的代码示例和配置方法。同时,文章涵盖了表格、图片处理、性能优化及生产环境部署指南,帮助Java开发者构建稳定、可控的文档转换服务。

weixin_29237635的博客 670

DSA(直接写屏)和双缓冲

<br />DSA(直接写屏)和双缓冲<br /> <br />http://blog.chinaunix.net/u3/103999/showart_2063360.html<br /> 1.DSA(直接写屏) 1.1介绍    使用GDI在屏幕上描画需要一个上下文转换,这会减慢描画速度。为了绕过繁琐的上下文转换,可以直接访问屏幕。这被称作直接屏幕访问。<br /><br />    直接写屏就是得到屏幕的显存地址,从而直接对显存进行操作,使用直接写屏是为了加快显示速度。<br /><br />    直

striker的专栏 1247

STM32F103+AX58100 EtherCAT从站SPI移植实战:CubeMX配置避坑指南

本文详细介绍了STM32F103与AX58100 EtherCAT从站控制器的SPI接口移植实战,重点解析CubeMX配置中的关键参数与常见陷阱。内容涵盖硬件连接规范、SPI模式设置、中断优先级规划及协议栈对接技巧,帮助开发者高效实现工业自动化领域的实时通信方案。特别强调CPOL/CPHA配置与AX58100的匹配要求,避免数据错位问题。

weixin_29230865的博客 330

WS2812b幻彩ARGB灯珠的STM32F103的DMA-SPI方式驱动

最近在做一个STM32项目,需要驱动24位WS2812b RGB灯环。曾写下一篇博文《WS2812b/2811/6812灯珠 – STM32F103 CPU-SPI方式驱动》。原理是:用SPI来模拟WS2812b的驱动信号时序。虽然这个程序能够正常工作,但也有一些缺点,其中一个最明显的缺点是——发送数据要占用大量CPU时间。那么有没有一种更好的办法呢?   这个方法就是用DMA-SPI发送。CPU...

爱莎女王的优快云博客 6485

YOLOv8 交通流量监测详解

本文介绍了一个基于YOLOv8的交通流量监测系统,该系统通过深度学习技术实现车辆实时检测、跟踪和分类。系统核心功能包括:1)使用YOLOv8模型检测道路车辆并进行持续跟踪;2)按方向和车型统计车流量;3)支持多区域流量监测和数据可视化。文章提供了完整的代码实现示例,涵盖基础车辆检测、视频流处理和高级数据分析功能。系统还可进一步优化性能,如使用轻量级模型、GPU加速等,并建议扩展车速估算、密度分析等功能。该方案为交通管理提供了有效的实时监测和决策支持工具。

u010117029的博客 345

YOLO26改进策略【YOLO和Mamba】| 2024 VM-UNet,高效的特征提取模块VSS block 二次创新提高精度

VM-UNet模型设计的出发点是解决现有CNN-based和模型在医学图像分割中的局限性,利用(SSMs)的优势,提出一种更有效的医学图像分割模型。具体来说,CNN-based模型在捕捉长距离信息方面存在不足,而模型由于自注意力机制的二次复杂度导致计算负担较重。SSMs模型如Mamba不仅在建模长距离依赖方面表现出色,还具有线性计算复杂度,这为VM-UNet的设计提供了理论基础。

Limiiiing的博客 211
上一篇: [Symbian项目进展]网络流量曲线图,代码+效果图
下一篇: Rendering (computer graphics)---From Wikipedia
WaveDHW
博客等级 码龄20年 455粉丝 159原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值