The compression is not visible (unless you create a picture where every pixel has a different color - but then again, that doesn't make sense).
There are basically two problems:
Speed and software code.
About speed:
When using the framebuffer, the data is written directly into the graphics RAM (basically directly into the system). This is the fastest thing you can do.
To rotate the image, you'd need to setup a temporary buffer where the image is stored normally (1280x720 pixels) and then transfer that RAM into the graphics RAM. The transfer is slow. AFAIR, when notaz made some tests, we found out the performance hit was huge (about 10% of original speed left).
When I ran Gambatte in a rotated X window, I had about 10 - 15 fps or something like that.
I'm pretty sure that when using the Vivante, we would still need to use that temporary buffer and would have the bottleneck of the RAM transfer.
About software:
Physically, the display appears to Linux as a 720x1280 screen.
So everything in Linux is setup to use it as a portrait screen: The normal terminal, etc.
X can be setup to use a rotated screen, yes. But that still makes things a bit slower.
However, if you want games without the performance hit from the rotation, you would need to basically code them in 720x1280 resolution.
Which means: You couldn't code in 1280x720 and then rotate it (that would slow things down again), you would need to use rotated sprites, etc. and code them in 720x1280.
Needless to say, this would be horrible for ports.
I'm also not sure if it would be easy implementing a low-level rotation function. It would need to be hacked into the kernel, otherwise you couldn't easily run a standard Linux distribution on the Pyra. You'd always need to include the hacked up SDL, etc. versions that include rotation (and still slow things down).
So whatever we are trying to do here, it would be some horrible hackup with slowdowns.
Unless we have a hardware that makes the LCD appear as 1280x720 to Linux.
There are basically two problems:
Speed and software code.
About speed:
When using the framebuffer, the data is written directly into the graphics RAM (basically directly into the system). This is the fastest thing you can do.
To rotate the image, you'd need to setup a temporary buffer where the image is stored normally (1280x720 pixels) and then transfer that RAM into the graphics RAM. The transfer is slow. AFAIR, when notaz made some tests, we found out the performance hit was huge (about 10% of original speed left).
When I ran Gambatte in a rotated X window, I had about 10 - 15 fps or something like that.
I'm pretty sure that when using the Vivante, we would still need to use that temporary buffer and would have the bottleneck of the RAM transfer.
About software:
Physically, the display appears to Linux as a 720x1280 screen.
So everything in Linux is setup to use it as a portrait screen: The normal terminal, etc.
X can be setup to use a rotated screen, yes. But that still makes things a bit slower.
However, if you want games without the performance hit from the rotation, you would need to basically code them in 720x1280 resolution.
Which means: You couldn't code in 1280x720 and then rotate it (that would slow things down again), you would need to use rotated sprites, etc. and code them in 720x1280.
Needless to say, this would be horrible for ports.
I'm also not sure if it would be easy implementing a low-level rotation function. It would need to be hacked into the kernel, otherwise you couldn't easily run a standard Linux distribution on the Pyra. You'd always need to include the hacked up SDL, etc. versions that include rotation (and still slow things down).
So whatever we are trying to do here, it would be some horrible hackup with slowdowns.
Unless we have a hardware that makes the LCD appear as 1280x720 to Linux.
