Platform: N270, 945GM
We are able to rotate the display by 90/180/270 degrees in Windows CE6 via the registry value "Rotation" in Port\2\General, followed by a restart.
However, some applications do not paint correctly with the display rotated. In one specific case, a C++ app is using InvalidateRect() to clear and force repaint of a portion of the screen; this code works fine when the display is in normal (0) orientation, but fails miserably with rotation - the invalidated area is never painted, making the app unusable.
I have confirmed the same problem with IEGD 10.4, although 10.3.1 is the preferred driver for our platform.
1. In the IEGD User's Guide, what does this mean: "Rotation is supported with Windows CE but only in static mode." ? Static mode is never explained in the document. Is this referring to "static memory model", via the ReservedMemoryBase/ReservedMemorySize settings? I have tried these settings, without success.
2. Is this problem one of the "limitations of the IEGD rotation implementation" discussed in past forum threads (such as: ) ? I am skeptical, since the code in question is using Windows GDI functions to paint text and straight lines on the display at very slow intervals (refreshed every .5 second); i.e., this is not a performance issue, and does not involve streaming video, animation or any such thing.
3. For Windows CE6 to properly recognize the rotated display, are there any other settings needed beside the above "Rotation" setting?
Any help would be appreciated!
1. By "static" we mean you cannot change rotation dynamically at run time. The system generally needs to know at initialization the desired rotation.
2. Rotation is being done by the driver by faking out the OS on the screen orientaion (the driver needs to lie to the OS as to the screen orientation), then on each frame, rerender the framebuffer to the appropriate rotation, so the hardware can shift out the image at the hardware native format, but with the data rotated. This is where the limitiations kick in. The "InvalidateRect" may be trying to do something directly in the framebuffer and missing the rerender step thus screwing up. We would generally recommened against rotation because of limitations and performance issues it causes. It is much better to find a display that runs actually runs at the desired orientation.
3. Rotation and an appropriate memory area for the extra oddly shaped framebuffer (there may be more off screen memory required to get the particular rotated resolution to match the memory stride) and the extra on-screen framebuffer to which we rerender with rotation the background framebuffer to display. Your memory settings may affect that but generally not.
You just may have found one of those roatation limitations in the wayt the software works the prevents rotation from working. I know it is not what you want to hear but it is what it is...
Hope this helps. Kirk