Rotation on WinCE6.0 and Windows mobile RRS feed

  • Question

  • I found that if the screen rotate 90 or 180 degree, a wmv file is played much more slower on WinCE6.0 than on Windows mobile.The hardware platform and the display drivers are the same.I will be appriciated if anyone tell me the reason.Thanks al lot.

    Wednesday, August 17, 2011 11:49 AM

All replies

  • Which processor you are using?
    Is it a pre-ARMv6 processor?
    If so, CE6 slower than CE5 on these processors is the expected result.
    There is a CE6 QFE allowing CE6 to enable CPU write buffer on memory aliasing (OAL needs to implement OEMSetMemoryAttributes), you may want to try it out to see if that help. For detail, please refer to

    Wednesday, August 17, 2011 2:48 PM
  • KMOS,

          My processor is based on ARMV5.

          I have noticed the difference of memoey allocation between WINCE5.0 and WINCE6.0 and I have also tried to change the attribute of the allocated memory, but it seems nothing improved.I will try the mothod you mentioned above.I will post the result later.Thanks in advance.

         Another problem,I have implemented overlay in DDraw driver,it works well when not rotated, but the overlay surface will not be created when the screen is rotated 90 or 180 degrees even if the CanCreateSurface function returned OK to create the overlay surface.Do you know how DDraw decides when overlay surface will be used?Thank you.

    Thursday, August 18, 2011 1:23 AM
  • hi,KMOS,

          I find that I have patched the package before,so it seems not effective.Any advice else?Thanks.

    Thursday, August 18, 2011 2:31 AM
  • I will check if the OEMSetMemoryAttributes is implemented correctly.
    Since this is an optional OAL function, make sure you have the following code in your OAL

        g_pOemGlobal->pfnSetMemoryAttributes = OEMSetMemoryAttributes;

    Also is your framebuffer enable WriteCombine (Write Buffer enabled) memory attribute? If not, there won't be any benefits. Otherwise it should make significant improvement on GDI and DDraw BitBlt operations.

    Thursday, August 18, 2011 5:38 AM
  • KMOS,

           Thank you for your quick reply.OEMSetMemoryAttributes is implemented and OEMInit is also modified.As you said, when I call CreateDIBSection, the page allocated actually has not PAGE_WRITECOMBINE attribute, but how to enable the attribute?Just enable the attribute for framebuffer?If it is allocated from system memory rather than from video memory, how to enable the attribute?Thank you.

    Thursday, August 18, 2011 5:58 AM
  • hi, KMOS

        My OEMSetMemoryAttributes is implemented as the following:

        BOOL OEMSetMemoryAttributes (
        LPVOID pVirtAddr,       // Virtual address of region
        LPVOID pPhysAddrShifted,// PhysicalAddress >> 8 (to support up to 40 bit address)
        DWORD  cbSize,          // Size of the region
        DWORD  dwAttributes     // attributes to be set
        if (PAGE_WRITECOMBINE != dwAttributes) {
            DEBUGMSG (1, (L"OEMSetMemoryAttributes: Only PAGE_WRITECOMBINE is supported\r\n"));
            return FALSE;

        return NKVirtualSetAttributes (pVirtAddr, cbSize,
                                      0x4,                  // not cacheable, but bufferable
                                      0xC,                  // Mask of all cache related bits

    Is it right?

    And I called CeSetMemoryAttributes to enable framebuffer with PAGE_WRITECOMBINE attribute.But the effect is even worse.Before the change, I set framebuffer with attributes cachable and wright through, And it is faster.Anything Wrong?

    Thursday, August 18, 2011 7:30 AM
  • The OEMSetMemoryAttributes looks fine to me.
    If I were you, I will print out some message or set a break point in OEMSetMemoryAttributes to ensure source and target buffer has been set to write combine mode during memory aliasing.
    Assue you have installed share source and applyied up to date QFE, you should see the SetMemoryAttributes call in UncachePage in private\winceos\coreos\nk\kernel\vm.c

    Regard to the performance, write through is usually better than write combine.
    Thursday, August 18, 2011 11:54 PM
  • I could see the SetMemoryAttributes call in UncachePage.

    I'm sorry but I don't know how to ensure the source and target buffer has been set to write combine mode during memory aliasing.OEMSetMemoryAttributes is only called during memory aliasing?I just need to call VirtualQuery function with pVirtAddr as parameter in OEMSetMemoryAttributes and print the information returned?Thanks.

    Friday, August 19, 2011 3:28 AM
  • VirtualQuery can't provide the write combine information but you can use VirtualSetAttributes ( with both dwNewFlags and dwMask == 0 and pass lpdwOldFlags to retrieve the current memory attributes (extract the C & B bits from the entry)
    Friday, August 19, 2011 5:39 AM
  • I have printed the attibutes  in OEMSetMemoryAttributes, the least 4 bits is 0x6.So the new flag has already been set.

    The write-combine attribute is even worse than write-through attribute here, for frame buffer, is it wrong?

    Any difference else between CE6.0 and PPC leads to the result?Thanks.

    Friday, August 19, 2011 9:04 AM
  • Here is some fundamental thing you need to know about.

    1. One of the major kernel change in CE6 is the user mode address management, from 32MB slot base to full 2GB space. That means the lower 2GB mapping changed when switching to different process.
    2. ARMv5 processor is VIVT cache, so cache can't survive (need to be flushed) during process switch and also need to temporally disabled cache (but write combine is still allowed) when memory aliasing.
    3. Although Write through mode usually has better performance, but due to the reason on 2, kernel need to disable it during memory aliasing or system can suffer cache coherency issue.

    When CreateDIBSection, both memory (the video frambuffer in kernel mode and the DIB buffer in user mode) should be turned in Write Combine mode.
    You can use VirtualSetAttributes to verify your user mode buffer attributes.
    Note that the VirtualSetAttributes is a kernel mode only API, you need to create a kernel mode DLL as a wrapper.
    Put it another way, you could remove the OEMSetMemoryAttributes and expect an even worse performance regression on DIB.

    For CE5 (PPC), as all processes share the same 4GB, there is no need to have memory aliasing and direct memory access is possible.
    General speaking, ARMv5 (VIVT data cache) usually has better overall performance on CE5 than CE6.

    Friday, August 19, 2011 1:16 PM
  • hi, KMOS,

         When calling CreateDIBSection, I found that the momery it allocated is not in Write Combine mode...

         And when I removed the OEMSetMemoryAttributes, it was not going worse...

         When I set write combine attibute the CreateCompatibleBitmap took longer time, and the CreateDIBSection did not change.

         When I set write through attibute the CreateCompatibleBitmap took shorter time, and the CreateDIBSection did not change.

         What happened?It seems that write combine mode just makes things going worse...

    Thursday, August 25, 2011 12:07 PM
  • Write combine is just a better replacement for non-cacheable and does not beat the performance of Write-Through in most of case.
    So if the memory alias (not the original frame buffer) is non-cacheable mapping, enable write combine should help, otherwise it makes no difference.

    Saturday, August 27, 2011 6:52 PM