1 of 1 people found this helpful
You are correct about double buffering on the rotated display as that is exactly what we need to do to perform the S/W rotation that we provide in IEGD. We present a buffer to the system that matches the target orientation (in your case 600 x 800 for 90 degree rotation) which the OS then draws into. For each screen update, we then re-render the 600 x 800 buffer with rotation to match the physical panel rotation then shift that data is shifted out to the display. The physical rotation of the screen and the s/w rotation of the data cancel each othert out and the screen looks proper. We have to re-reneder each screen which is why you see a slow down in performance. S/W rotation is a huge burden on the system and we usually recommend people avoid it by using panels or displays that physically match the desired orientation.
That said, it does sound like we may have introduced an issue was introduced in the 10.4 code release for rotation although I am not aware of any currently open issues against the 10.4 release around rotation.
To verify, I would recommend trying a fresh/clean install instead of doing an upgrade from 10.0 to 10.4. You will probably want to be sure to generate a new installation image with CED with all 10.4 files to be sure you do not have any left over settings or driver files from 10.0.
I can provide the 10.0 release to you however it is too big to upload here so we would need to figure out a different way to accomplish it. We normally provide that sort of thing through our Premier Support (Quad) system.
Thanks for the 10.0 - we get our performance back with that.
We have discovered an issue with the 10.0 and this setup (with remote desktop sessions into the device) that we didn't see with 10.4 based drivers - do you think the 10.4 performance issues with a rotated display are likely to be addressed at any point?
(I'll file the 10.0 issue with remote desktop as another post - if there is a fix for that, we can stick with the 10.0 based driver).