timing issues wirth SHOWSCREEN?

[spacefractal]

There is something mystery going on.

What do SHOWSCREEN really do?

I have some very much perforcement drop when SHOWSCREEN is called. its take woppy 55ms secs for that that command alone?

Do all draw elements first called when SHOWSCREEN is used, or? There is a issue with SHOWSCREEN on Android I are not aware what it happens.

For when I check what I draw commands used, its on 12ms secs, while the update loop is 16ms.

The goal is 30FPS, which is round 33.33ms per tick, but I wonder why SHOWSCREEN alone take woppy 55ms? I throught it only flip the buffer, or does it draw first when that command is called?

Its look like ots something software render that have not been disabled or such, since its take long time to flip to the backbuffer. That even when I use LIMITFPS -1, the ms taken to use that command was still 55ms.

The is no problem on iOS 3gs, where SHOWSCREEN to max 3-4 on very extreme load (but FPS still fall due longer ms on paint(), which is excepted).

[Kitty Hello]

Many drivers buffer all draings for being flushed on a glSwap. Might be the case here.
It does a lot of other things, but they are all required.
You can't get 60 FPS with a blank WHILE; SHOWSCREEN; WEND?

[spacefractal]

Its the MS taken on SHOWSCREEN its wonder me. on iOS, the Paint() ms is just higher (all excepted), while SHOWSCREEN was stable or very few ms higher. on Android the SHOWSCREEN ms is very high (there is a lots of graphics), but still its only Paint() that should just been higher. Its that wonder me.

Its look light a driver issue for that Phone, or?

PS. Could its possible because the graphics is on software mode, rather than hardware mode for some reason?