Am 15.07.2014 um 12:49 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Tue, 15 Jul 2014 08:10:37 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
just tried a few more things with that turbo driver.
Moving windows is a lot faster (after the initial hang), as mentioned. Battle for Wesnoth is still really slow, which was to be expected, as it's updating the fullscreen, the trick the turbo used wouldn't have helped here.
I switched Wesnoth to window mode. If the Window is roughly 1024x768 in size, Wesnoth is smooth and blazing fast. The bigger it is, the more stuttery it gets, so it's certainly something that has to to with refreshing the screen.
I'm not sure how smart X works. For example, if you move the map in Wesnoth, does it redraw the full screen as every pixel changes, or is it smart enough to figure out that the content has just moved a bit and moves it instead of redrawing it completely? (That's how video compression works)
I think in X it depends on what the client application instructs the X-Server to do. There are move-commands and it is possible to redraw a bitmap at a different location.
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
This looks like an X-event/GUI-library issue to me. Maybe the client code tries to redraw for each event even if the window is just moved around (which can be done bit blitting in the x server). Ah, yes. This is very likely. If you move a window - and have the wrong settings for backing store, this creates redraw events for each rectangle that becomes unobscured by moving the window away. This redraw event is sent to the client which must render the portion of the screen again.
Is that a setting you can apply somewhere? I didn't find anything like that in X' configuration options. Or is that something that needs to be fixed in the driver?
IMHO this is chosen by the GUI toolkit. Or maybe a X server command line option?
Graphics Memory size was on the bootargs of the BeagleBoard but I don’t know if it still exists on the OMAP5 kernel.
If there is backing store enabled, the portion becoming unobscured can be redrawn from some buffer within the X server.
Okay, so I guess that's basically what I mentioned above with Wesnoth as well? If the screen portion moves, no need to redraw it but simply move it?
I have doubts about your theory of limited memory bandwidth. On the GTA04 (or OpenPandora) we have 640x480 pixels which is just 1/7 of Full-HD. So the OMAP5 should not have to do more than 7 times as much work and bandwidth demand as the OMAP3.
Are you using 32bpp or 16bpp? The Pyra is currently using 32bpp, which increases the bandwidth a lot as well (though the question is whether we even need 32bpp)
Hm. I don’t know for sure. Most likeley it is 24bpp (since we have a 24bit WVGA panel on the Letux 7004).
32bpp is not really needed but should IMHO even be faster since it does has a direct memory-word <-> pixel mapping. 24bpp might need to read two memory words (32 bits each) to get a pixel.