Symbian developer community

 
Home > Wiki> Graphics(Redirected from Graphics Package/KhronosReferenceImplementation) > KhronosReferenceImplementation
wiki

Graphics/KhronosReferenceImplementation

From Symbian Developer Community

Jump to: navigation, search

The purpose of this page is to co-ordinate the efforts of the community around the Khronos Reference Implementation as it applies to the Symbian OS platform.

There has already been volunteer work that has been done on the graphics FCL to integrate the reference implementation of OpenVG and EGL from Khronos. More interest has arisen for this project. A wiki page is needed to enumerate the goals of the project. This is so different committers can see the direction being taken, and thus share a common development aim.

A note of warning to the reader. This page may appear somewhat chaotic and haphazard. Its a collective scrap book of ideas and work in progress. It will be replaced by something more organized as things settle down.

For more contextual information, see the Graphics Wiki

Contents

Project Requirements

Requirements are:

  • it is unencumbered of third party intellectual property
  • it gives useable UI performance on emulator, or simulator, or other reference platform
  • contributions are made back to Khronos

The reasons for this are:

  1. We want widespread adoption of Khronos client side APIs in the community. For that, application writers, who dominate the community by the number of them, should be able to write, test, and debug applications which use Khronos APIs. They therefore need a minimal barrier to entry. This means access to a reference implementation of the Khronos APIs ready integrated, and useable for development purposes.
  2. The reference platform will be different for different people. We are in a process of change. The WINSCW emulator will be obseleted but today it works well. The replacement will either be a proprietary simulator, which is suited for a Nokia-aligned audience, an open simulator, which is suited to device creators and open source platform creators.
  3. We are part of a wider open source community. We should give back to the community enhancements we make to the Reference Implementation; it is part of the commons.


The consequence of this is that all code must be under one of the following licenses:

  • Khronos license
  • Symbian Foundation License
  • Eclipse Public License

Project Goals

The goals of the project are declared by the committers who are actually doing the work. Our current goals are:

  1. Analyse performance of the OpenVG implementation, and document findings
  2. Contribute performance optimizations to OpenVG RI in the FCL

Architectural Forces

Choice of EGL

  1. Khronos RI EGL is common to the whole community. Adding to this helps the community.
  2. Nokia Contributed eglrefimpl will be the MCL standard. It only supports OpenWF use cases.

Lets build on whatever is working on the FCL. When mature, we can have an informed debate.

Choice of Platform

  1. The Khronos RI runs on Windows and Mac. Now also on Symbian OS (I need to validate this statement).
  2. WINSCW emulator works today. Platsim (Nokia Forum distributed nokia simulator) should work, needs testing.
  3. Real hardware (needs a port) such as Beagle Board

Committers can use their preferred platform. They must document any special setup required on this page. They must help others fix regressions on their preferred platform.

Working Practices

Source code

We'll use the graphics FCL. Anyone can commit working code so long as it is agreement with the Project Requirements (see above). This is that there is a low barrier to entry. We can then make quick early progress and gain implementation experience. More formalism will follow later where we may need a separate project tree, start running system testing, and plan for a contribution back into MCL.

Communication

The primary form of communication should be articles on this wiki project page. This saves people the bother of keeping up with lots of email. Some discussion is needed. The standard discussion forums and mailing lists should be used:

We'll setup something project-specific if the volume of traffic requires it. In the early phase, we'll want wider comments and remarks from the user interface subscribes so we don't miss important constraints or use cases.

Development Environment

We expect a number of different development environments for this project. This will need to be rationalised to a working common denominator amongst the committers.

Faisal Memon: Working on Nokia Internal Setup

I am bootstrapping based off Nokia Internal TB92 Week 44. This is not ideal. I would prefer just a SF PDK. But in the bootstrap phase its useful to have a wider view of various options to understand the dependencies and debug.

I have created a feature branch faimemon_khr_ri_nga_config currently at changeset 352f647cc5cd in the graphics FCL to share this work. This is branched off RCL_1 which was the original Khronos Reference Implementation work. 

changeset:   36:352f647cc5cd
branch:      faimemon_khr_ri_nga_config
tag:         tip
parent:      30:44b3a7c5f666
user:        Faisal Memon <faisal.memon@nokia.com>
date:        Tue Dec 08 18:58:45 2009 +0000
summary:     Initial faimemon_khr_ri_nga_config changes.

I am also compiling (for the sake of being able to breakpoint) the Svgt FCL, at version 

changeset:   27:efac43e64814
parent:      24:6a86cdc5375a
user:        Mikko Sunikka <mikko.sunikka@nokia.com>
date:        Fri Nov 06 14:37:00 2009 +0200
summary:     Revision: 200943

Upon booting, both AvkonIcon and Hitchcock instanciate the NVG engine successfully. Alf then panics. Its because 

17 CHuiVg10RenderSurface::CreateSurface() Y:\sf\mw\uiaccelerator\uiacceltk\hitchcock\CORETOOLKIT\RENDERVG10\src\HuiVg10RenderSurface.cpp:196 0x1a157771

Due to a casting problem, we get a memory allocation failure. The Khronos EGL thinks its been asked to create a PBuffer surface for a huge surface: 

19 do_eglCreateWindowSurface() P:\hg\khr\graphics\openvg\openvgrefimplementation\sfopenvg\sfopenvg\riMiniEGL.cpp:1481 0x184e0716	
windowHeight	529925928	
windowWidth	327684

The problem is that Alf passes down a RWindow* but the RI EGL is expecting a CFbsBitmap*.

I created changeset 352f647cc5cd on the graphics FCL to fix this problem.

Now the Alf Render stage causes a panic because there is no Alf native layer in the scene. 

12 CAlfRenderStage::AlfWindowListenerCallBack() P:\sf\mw\uiaccelerator\uiacceltk\hitchcock\AlfRenderStage\src\alfrenderstage.cpp:1865 0x1aa456cc

I haven't made progress with this bug. I think the problem is that the initial layers (or rather Elements in OpenWF terminology) are not being correctly added, and what we see here is a side-effect of that problem. Therefore I am going to change track, and see what it would take to produce a version of the Alf Render Stage which used OpenWF as its Compositor instead of a proprietary Compositor.

Once that it is done, I hope the listener callback code above works ok. Then we're back on trying to get Khronos RI EGL working.

Porting the Alf Render Stage to OpenWF

  • Change proprietary composition wrapper class to the OpenWF Composition Wrapper COpenWfcWrapper from graphics/windowing/windowserverplugins/src/openwfcwrapper.cpp
  • Change proprietary wrapper class to undertake element management to CElementWrapper from graphics/windowing/windowserverplugins/src/elementwrapper.cpp
  • Code handles the Window Server Display Control API. I cannot find an OpenWF equivalent. Would need to disable support for MWsDisplayControl in the short term in alfrsdisplaycontrol.h.

Whilst porting, I had to sync up to the NewGraphicsArchitecture tag of the graphics package to get the OWF stuff. Note this means re-compiling

  • eglinterface (to get khrplatform.h)
  • graphicscomposition/openwfcinterface (to get remaining OpenWF headers)

I also had to bring across displaypolicy.* from the reference stdplugin display rs.

There is also a need to create a new pair of UIDs to represent the plugin dll and plugin dll implementation. I seem to be having problems getting the UID allocated using internal (nokia) tools.

I am starting with an oldish Alf RS (week 44). I'll re-base on the latest Alf code next year because I'll then be back on the corporate network to pull the largish data sets required.

This work is in hg but local; its going to be under FCL branch faimemon_experimental_alfowfrs. Need to make more progress:

  • removing proprietary stuff
  • placing stub openwf calls
  • possibly using EPL not SFL license (nice to have)

I'll need to touch base with the uiacceltk package owner as well.

As soon as it is up on its feet we'll hit a problem mentioned by William. That is getting a unified EGL working because the OWF based RS will in turn need EGL 1.4 Sync object code which is not currently present in the Khronos RI EGL.

Further thoughts on Porting Alf RS

I chatted with the package owner, Markus Penttila.

  • They are planning on a refactored Alf RS solution, by pushing the compositor code and the co-ordination code with the Alf rendering thread into its own RS.
  • Currently the TPIP in Alf RS is purely the compositor code, nothing else.
  • When the Alf RS is refactored to use OpenWF, you won't be able to see transitions because the transitions are controlled through a mark-up language. Reference files to demonstrate this mark-up language will instead be supplied.
  • The UI experience really requires Alf RS, the mark-up language for transitions, and hardware to drive the whole experience

So strategically, the best thing to do here for emulator is to stick with the bitgdi standard display RS, with the extended bitmap RS to provide icon support, and demonstrate the whole thing in software.

A later step is to get everything working on hardware, and at this point, there is a value add to introducing the Alf RS, together with some transition effects fxml files.

William Roberts: Symbian Foundation team working on PDK 2.0.1

We're using PDK 2.0.1 and the same changeset that Faisal mentioned (44b3a7c5f666). The code compiles ok for winscw (warnings but no errors) 

 
sbs -b \sf\os\graphics\openvg\openvgrefimplementation\sfopenvg\group\bld.inf -c winscw_udeb
sbs -b \sf\os\graphics\openvg\openvgrefimplementation\sfopenvg\group\bld.inf -c winscw_udeb.test
 

The test code is the "Tiger" demonstration. Adding "--what" to the sbs commands shows: 

 
epoc32\include\eglosnativewindowtype.h
epoc32\release\winscw\udeb\libopenvg.dll
epoc32\release\winscw\udeb\libopenvgu.dll
epoc32\release\winscw\udeb\libEGL.dll
epoc32\release\winscw\udeb\libvgi.dll
epoc32\release\winscw\udeb\sflibopenvgrefimpl.lib
epoc32\release\winscw\udeb\sflibopenvgrefimpl.dll
 
epoc32\include\tiger.rsg
epoc32\data\z\\resource\apps\tiger.rsc
epoc32\release\winscw\udeb\z\\resource\apps\tiger.rsc
epoc32\release\winscw\urel\z\\resource\apps\tiger.rsc
epoc32\localisation\tiger\rsc\tiger.rpp
epoc32\localisation\group\tiger.info
epoc32\data\z\private\10003a3f\apps\tiger_reg.rsc
epoc32\release\winscw\udeb\z\private\10003a3f\apps\tiger_reg.rsc
epoc32\release\winscw\urel\z\private\10003a3f\apps\tiger_reg.rsc
epoc32\localisation\tiger_reg\rsc\tiger_reg.rpp
epoc32\localisation\group\tiger_reg.info
epoc32\release\winscw\udeb\tiger.exe
epoc32\release\winscw\udeb\z\test\sfopenvg\winscw.auto.bat
epoc32\release\WINSCW\UDEB\Z\resource\apps\tiger_icon.mif
epoc32\release\WINSCW\UDEB\Z\resource\apps\tiger_icon.mif
 

There's an nvgencoder.log file produced which says 

 
unsupported element image (M:\epoc32\BUILD\s60\icons\temp\scb8.tmp\.._gfx_qgn_menu_tiger.svg)
 

but this doesn't seem to be a problem in practice?

  • FIXED - The Tiger app doesn't show up anywhere in the UI

It should be at the bottom of the "Applications" folder, though it might be almost impossible to see in the "List" view. Try deleting the cache of applications - epoc32\winscw\c\private\10003a3f\AppsListCache\* Alternatively, launch "eshell" from the Applications folder and type "tiger".

  • FIXED - Launching "tiger" produces a KERN-EXEC 3

You need to increase the "MegabytesOfFreeMemory" setting in epoc.ini from 48 to 128. If it crashes, the epocwind.out file might contain 

 
   362.685	If rendering fails with KErrNoMemory then you must modify epoc.ini file 
   362.685	to increase the maximum total heap size e.g. to MegabytesOfFreeMemory 64.
   362.685	The Kronos ref OpenVG seems to use a lot of heap so when both NVG engine
   362.685	and the Tiger app are active it pushes it over limit of 48Mb.
 

Even though it says "64", you will find that 128 is better for the next step...

  • Use the OpenVG Reference Implementation for all rendering

The sfopenvg component produces versions of libopenvg.dll, libopenvgu.dll and libEGL.dll which all just pass requests across into sflibopenvgrefimpl.dll, which is built defining BUILD_WITH_PRIVATE_EGL (etc) to include private implementations of EGL, OpenVG and VGU. It also produces a version of libvgi.dll which operates through the Font & Bitmap server and EGL.

To enable the use of the OpenVG reference implementation for all rasterisation of icons, it is sufficient to change to the OpenVG version of the SVG Engine: 

 
copy epoc32\release\winscw\udeb\SVGEngine_OpenVG.dll epoc32\release\winscw\udeb\SVGEngine.dll
 

This will correctly render the SVG icons which are currently encoded in SVGB format.

The tiger app is using the libOpenVG.dll interface directly, so the fact that it draws the tiger correctly gives some confidence that icons in the extended bitmap format would render correctly as well - this has been confirmed by building the MIF for the tiger app icon using SVGENCODINGVERSION 4 to force the use of the extended bitmap format.

  • Build for ARMV5

Some work was needed to make the sfopenvg code compile with RVCT. It needed the correct use of EXPORT_C and extern "C" {} to get libEGL.dll etc built correctly, and then some fixes to the get the real implementation to build. The most significant change is the switch from estlib.lib to libstdcpp.lib to get proper support for try/catch, and the removal of the non-functional "mutex" in the riEGLOS.cpp file which caused the DLL to have writeable static data.

The graphics\graphicsaccelaration\vgi component was also providing an implementation of vgi which passed through to a function inside libOpenVG.dll, so we've removed that transitional code in favour of using the "proper" EGL-based implementation in the sfopenvg\vgi\vgi.cpp.

The resulting revision is 87380edf93a3 which has been seen working in a Zoom2 ROM, though the tiger took so long to render that we thought it had hung!

  • Delivered in PDK 2.0.2

These changes are delivered in PDK 2.0.2.

Proposal to add the Khronos OpenVG Reference Implementation to Symbian^2

Bug 31 is being used to propose adding the Khronos OpenVG Reference Implementation to Symbian^2. Feedback from Fasial has changed the names for some directories and DLLs, and separated the libEGL.dll implementation out into a separate component. Latest version is d91278890ee9.

William Roberts: Working on Symbian^3

As part of the work towards PDK 3.0.d, we have tried building and running the OpenVG reference implementation. It builds OK, but the generated libEGL.dll clashes with the one generated from sf/os/graphics/egl/eglrefimpl.

  • WORKAROUND - libEGL.dll clash, "EGL 1" panics

The eglrefimpl version of libEGL is a subset of EGL 1.4 which exists to provide synchronisation support for OpenWF. If we use the sfopenvg version of LibEGL, the default render stage doesn't load correctly. If we use the eglrefimpl version, then real use of EGL causes "EGL 1" panics.

The "EGL 1" panic is the generic PANIC_NOT_SUPPORTED function which is used for most of the functions in egl/eglrefimpl/src/entrypoints.cpp, so it just means that ALF and Tiger are trying to do real operations like creating surfaces.

The workaround is to generate the sfopenvg EGL interface to a different dll name, e.g. libEGL_sw.dll. See revision e902481bc400. This has added "_sw" to libopenvg and libopenvgu as well, which allows various additional DLLs to build, including the AknIcon fbsrasterizer.dll.

The tiger app works out of the box (provided it links to libopenvg_sw) and the tiger is correctly drawn, if you can navigate successfully through the UI to launch the app.

Wish List Item - Single unified EGL

The refeglimpl and sfopenvg EGL should be unified into one EGL which supports both the OpenVG reference implementation and the needs of OpenWF.

Wish List Item - SVG icons rendering correctly on Symbian^3

We really want to have the SVG icons rendering correctly on Symbian^3, because it will make the debugging of other problems so much easier, and it makes the thing presentable. There are various ways this might be hacked, but the most architecturally sound approach is to add a render stage which understands the extended bitmap file format and uses the NVG decoder to issue OpenVG commands to make a conventional CFbsBitmap.

The current state of Symbian^3 means that we need to rely on the "flickerbuffer" render stage, which works with OpenWF but doesn't handle the extended bitmaps. In a few weeks we look forward to having the productised ALF render stage adapted to support OpenWF, but it's not available yet.

Some clues and places to start:

Step by step
  • First build the t_extendedbitmap renderstage and configure it into the emulator. 
sbs -b \sf\os\graphics\graphicstest\graphicstestharness\group\bld.inf -c winscw_udeb.test
sbs -b \sf\os\graphics\windowing\windowserver\test\t_extendedbitmap\group\bld.inf -c winscw_udeb.test -k

The graphicstestharness is needed because it owns some of the headerfiles and creates some libraries. The -k is needed bcause the test code to exercise the t_extendedbitmap render stage will not compile (needs some extra stuff), but we don't need it.

Edit the epoc32\release\winscw\udeb\z\system\data\wsini.ini file to add 

 
PLUGINS TEXTENDEDBITMAP FLICKERBUFFER DISPLAY
RENDERSTAGES textendedbitmap flickerbuffer display
 
[TEXTENDEDBITMAP]
ID 0x1028653B
 

Note that the emulator uses "DISPLAY", not "STD" at the bottom of the stack, and the names in the RENDERSTAGES line are case sensitive. Not sure if AKNEXTENDEDFADER is relevant, so I've left it out. Emulator still boots just the same (as expected).

  • Add some tracing to find out what's going on

I put some tracing into all of the functions in textendedbitmaprenderstage.cpp which check for KUidExampleExtendedBitmap, and print out the ExtendedBitmapType() for those bitmaps - the popular answer is 0x39b9273e, but the cross-referencer doesn't like looking for that sequence of characters. Callers of ExtendedBitmapType() usually only care if the result is KNullUid or not, and don't look at the value.

The calls are almost exclusively 
BitBltMasked(const TPoint& aDestPos, const CFbsBitmap& aSourceBitmap, const TRect& aSourceRect, const CFbsBitmap& aMaskBitmap, TBool aInvertMask)
where both source and mask are extended, but the initial "Heart logo" splash screen is drawn with 
BitBlt(const TPoint& aDestPos, const CFbsBitmap& aSourceBitmap)
. Just for fun, let's process the NVG encoded data as though it was "flags of the world". 
 
const TUid KUidExampleExtendedBitmap = {0x39b9273e};  //{0x10285A78};
...
		// iGc->BitBltMasked(aDestPos, *sourceBitmap, aSourceRect, *maskBitmap, aInvertMask);
		iGc->BitBlt(aDestPos, *sourceBitmap, aSourceRect);
...
	// Get the size of each stripe
	stripe = 1;  // force them all horizontal
	if (stripe == 1) // Horizontal stripes
 

We need to get rid of the mask bitmap otherwise things don't appear, and we need to make the GetFlagData function less fussy about the validity of the input data. Mostly look a nasty brown/purple combination, but stuff is happening. Pushed to the FCL in a branch called NVG_Render_stage, rev 41824b8b3536.

  • Try throwing the data into CNvgEngine::DrawNVG

The extended image format has a TAknIconHeader on the front, so the actual NVG commands live a bit further on: 

 
	TRAP(err, iGraphicsInterface->InitializeL(aExtendedBitmapSrc.SizeInPixels()));
	if (err != KErrNone)
		{
		iExtendedBitmapError = err;
		return;
		}
 
	// Clear to White before doing anything else
  VGfloat color[4] = { 0.0f, 0.0f, 0.0f, 0.0f };
  vgSeti(VG_SCISSORING, VG_FALSE);
  vgSetfv(VG_CLEAR_COLOR, 4, color);
  vgClear(0, 0, size.iWidth, size.iHeight);
 
  aExtendedBitmapSrc.BeginDataAccess();
  const TUint8* bmpData = (const TUint8*)aExtendedBitmapSrc.DataAddress();
  TInt dataSize = aExtendedBitmapSrc.DataSize();
  // skip TNVGIconHeader structure - we only know about version 0
  if (bmpData[2] == 0)
    {
    TInt headerlength = bmpData[3];
    bmpData += headerlength;    
    dataSize -=  headerlength;
    }
  TPtrC8 nvgData(bmpData,dataSize);
 
  TInt error = iNvgEngine->DrawNvg(nvgData, aExtendedBitmapSrc.SizeInPixels(), &aBitmapDst, NULL);
  RDebug::Printf("DrawNVG returned %d from processing up to %d bytes\n", error, dataSize);
  aExtendedBitmapSrc.EndDataAccess(ETrue);
 
  TRAP(err, iGraphicsInterface->CopyBitmapL(&aBitmapDst, NULL));
	if (err != KErrNone)
		{
		iExtendedBitmapError = err;
		return;
		}
 
 

The CNvgEngine needs to be given a Graphics implementation, for which I've copied the vgigraphicsinterface.cpp used by svgtfbsrasterizer (and added lots of includepaths which are really only appropriate for the mw layer!). The final nuance is that nvgdecoder.dll links to libOpenVG which is a stub, rather than libOpenVG_sw.dll which would actually do some drawing: t_extendedbitmapbitmaprenderstage.mmp needs to use nvgdecoder_sw.lib. It's now coming out looking about right (rev 5a55762d0847) if you can fight your way through the confusion. I have seen some ViewSrv 14 panics.

  • Stop the chaotic redrawing

Switched on logging - see File:Wserv.log.zip which shows the overwriting sequence: splash screen, OK button, "ALF EGL 1 panic", standby screen background, Menu app, Standby screen again, "S60 logo animation", Menu with "Locked" status, Log app ("Dialled Calls") and Messages.

Note that the instructions on switching on logging are slightly wrong for Symbian^3 - the magic is: 

 
LOG FL
LOGP C:\DATA\WSERV.LOG
LOGENABLE 1
 

You don't need the autoclear or screenmode commands, and the LOGENABLE needs a "1" in order to trigger immediately on startup.

Faisal identified the use of "CHANGETRACKING" in wsini.ini as the cause of the problem. The description of Change Tracking mode says that it makes the render stage(s) responsible for tracking window visibility in the scene, and the visual results are consistent with the failure to track visibility in the depth ordering.

The CHANGETRACKING keyword was there for the ALF render stage, which does do it's own tracking (for transition effects). Removing the keyword seems to make the emulator boot slowly, but the display now look rights, and behaves correctly (if rather unresponsively). The slowness is presumed to be a performance issue in the OpenVG reference implementation, to be investigated further.

  • Repackage and put somewhere more appropriate

In line with Faisal's suggestion, I have now tided this up and put it as a new component /sf/mw/uiresources/uigraphics/NVGRenderStage - see rev 5c51eb98adf2 in the uiresources FCL. The change includes altering the wsini.ini file to load the plugin, configure the renderstages and turn off change tracking. The files are all "Copyright Nokia" and under the Symbian Foundation License, as I don't consider that we've done very much to the example code on which it is based.

We intend to publish this as PDK 3.0.e.

  • Add caching layer

The performance of the UI is slow due to icons (largely static content) being repeatedly re-rendered. Instead of throwing away the rasterized bitmap each time, a simple LRU caching was added. This can be done because each extended bitmap has an identifier for each icon: using that identifier and the handle to the extended bitmap makes a key into a cache table of pre-rendered CFbsBitmaps. The current solution is in rev 666af629a621 - the number of cached bitmaps is set when the render stage is constructed, but a production solution would probably want a configurable size (perhaps as a ROM patchable constant?).

This solution is essentially a time vs. space trade-off; we run more quickly but consume more RAM.

This version will be supplied as a patch to PDK 3.0.e.

This does not solve the underlying performance (and memory footprint) issues of the reference implementation of OpenVG. But it does make the PDK usable.

Outstanding bugs

Bug 1557 is a splashcreen.mif which works as expected on the OpenVG implementation used inside Nokia, but not using the port of the Khronos OpenVG in Symbian^3. The first path in the icon fails in some way, which prevents the rest from being drawn. This works on PDK 2.0.2, which is interesting...

Deep Prakash (Accenture): Fixing icon rendering on Symbian^3 emulator

Currently on Symbian^3 emulator, icon and skin rendering doesn’t work. Symbian^3 introduces NGA with key concepts such as render-stages, extended bitmaps and OpenWF composition. Any issues around the integration of these components could easily lead to imperfect icon rendering on Symbian^3. Hence we only see text rendering on the Symbian^3 based emulator. We have identified two approaches to solve this issue:

Approach 1: Symbian^2 style icon rendering with OpenVG rasterizer

Shabe currently has a Symbian^3 environment where he has successful y got the icons and skin rendering using 3rd party mif rasterizer. He compiled the entire Symbian icons in the svg-b based mif format and used Symbian^2 SVG engine with 3rd party rasterizer to rasterize svg-b data to the CFbsBitmap. In the process, AknIcon Server started complaining because Symbian^3 icon Server expects NVG –CS (Command Section) based mif icons which it can store in extended bitmaps. The easy solution was to replace Symbian^3 AknIcon Server with the Symbian^2 icon Server and get a working emulator. Flicker-buffer and display render-stages along with OpenWF composition don’t seem to create any issue as long as they have CFbsBitmap input which the proposed solution succeeds in achieving. Since the above approach contains 3rd-party rasterizer, it’s not possible to contribute to the Symbian Foundation and to the external world. Replacing this with a Symbian Foundation OpenVG rasterizer is an obvious solution. Symbian Foundation OpenVG uses open-source OpenVG solution with EGL adaptation for pixmap/CFbsbitmap and DSA based rendering. In practise, this doesn’t seem to work. I can only think of conflicts with multiple EGl libraries that are currently existing in the Symbian^3 code-line as the potential reason for failures. There are at least 3 implementation of EGL in the Symbian^3 code-line which either does partial or duplicate role of fully-functional EGL. (Refer to William’s note of EGL unification wish-list). Fixing EGL would potentially lead to a successful build based on Approach 1. Watch out for the solution as we solve this issue.

Approach 2: Symbian^3 style icon rendering with OpenVG renderer

This approach is mandated by the Symbian^3 architecture. However, we seem to be a bit away to fully understand the implications of extended bitmaps and integration with flicker buffer/Display render-stages (rather than ALF render-stage). Our first goal is to capture the input which is fed to the display render-stage and compare it to that fed to the display render-stage of Approach 1. We should also remember that Symbian^3 uses NVG-CS based mif icons which gets stored in extended bitmaps and passed to the flicker-buffer render-stage which doesn’t seems to have the capability to render it.

As the next step, I chained example/test extended bitmap render-satge plug-in before flicker-buffer and display render-stage. Interestingly, we can see the extended bitmaps falling into the blit function of example extended bitmap render-satge plug-in. Since, it can only decode the extended bitmap format of UID KUidExampleExtendedBitmap and not KUidNvgProprietaryFormatires, it tries to render those extended bitmaps as the normal bitmap and hence fails on the way. Moving forward, I am trying to integrate NVGdecoder inside test extended bitmap render-stage plug-in to decode input extended bitmaps.

NVG deocder is now integrated into the extended bitmap render-stage plug-in. Please follow the instructions from the William's note in the pragraphs above. S60 icon and skin rendering works well in the Symbian^3 environment. However, There is an issue around window focus, which is currently under investigation.

Project Status

Code Status

William has got PDK 2 working on hardware (Zoom2) but it is slow. Now working to get it into a form which would be acceptable for contribution into Symbian^2.

William has got PDK 3 working on emulator. An LRU cache for icons was introduced; PDK now responds reasonably quickly and shows a correct UI.

Faisal is switching over to the PDK approach, and is going to focus on khronos reference implementation profiling and performance analysis.

MattD has transplanted the Symbian3 'NewGraphicsArchitecture' branch onto the OSS FCL, so it's easier for others to work on, and we can have booting OSS PDKs. Just remember it's not the default branch...

Management Status

The management status of the project is "released in PDK 3.0.e+patch, awaiting community feedback". PDK 3.0.e

Retrieved from "http://developer.symbian.org/wiki/index.php/Graphics/KhronosReferenceImplementation"

Comments

Sign in to comment…