Hardware surfaces on handhelds

Hi,

I’ve been thinking about implementing support for hardware surfaces in the PicoGUI driver for SDL. This might be useful also for the Qtopia, Nano-X, and framebuffer drivers on handhelds.

The problem is, many handhelds (specifically the iPaq and Zaurus) use a 320x240 LCD mounted in a portrait orientation, so that the display has to be rotated in software to compensate. Most GUIs do this automatically, but to give the application direct access to the framebuffer the app has to be aware of the rotation.

I’d like to be able to have rotation-aware applications access the framebuffer directly on handhelds like this while non-rotation-aware apps go through the GUIs rotation layer. How should this be implemented in SDL? Maybe a flag to SDL_SetVideoMode?

–Micah–
Only you can prevent creeping featurism!

The problem is, many handhelds (specifically the iPaq and Zaurus) use a
320x240 LCD mounted in a portrait orientation, so that the display has to be
rotated in software to compensate. Most GUIs do this automatically, but to
give the application direct access to the framebuffer the app has to be
aware of the rotation.

Well, on the iPAQ at least, the way you access the framebuffer is in
landscape mode. It’s the portrait mode that is ‘not natural’ (ie it’s the X
server or the frame buffer device that does the rotation for the user whn in
portrait mode).

For this to work, the easiest is to always have SDL return the 'real’
dimensions of the screen (ie 320x240 in this case) and it’s the game
author’s responsability to do the rotation himself. But for that to work,
SDL would also to communicate with the underlying graphic architecture to
tell it that the given bffer to display is already in 'hardware-oriented’
mode.

                        Lionel-- 
	 Lionel Ulmer - http://www.bbrox.org/

The problem is, many handhelds (specifically the iPaq and Zaurus) use a
320x240 LCD mounted in a portrait orientation, so that the display has to be
rotated in software to compensate. Most GUIs do this automatically, but to
give the application direct access to the framebuffer the app has to be
aware of the rotation.

Well, on the iPAQ at least, the way you access the framebuffer is in
landscape mode. It’s the portrait mode that is ‘not natural’ (ie it’s the X
server or the frame buffer device that does the rotation for the user whn in
portrait mode).

For this to work, the easiest is to always have SDL return the 'real’
dimensions of the screen (ie 320x240 in this case) and it’s the game
author’s responsability to do the rotation himself. But for that to work,
SDL would also to communicate with the underlying graphic architecture to
tell it that the given bffer to display is already in 'hardware-oriented’
mode.

Well, the problem with this is that some applications might want the GUI or SDL backend to do rotation for it. IMHO this should be the default behavior, for consistency with the GUI that SDL would be running under. There should be a way for SDL to advertise to the app that the screen is really being rotated behind the scenes, then if the app still wants direct access it can get information about what kind of rotation is used (90 degrees, 270 degrees, etc.) and do the rotation itself.

Another possibility might be that for apps that only use blitting and other SDL builtin functions, that it rotates the coordinates of the blits, and rotates teh bitmaps at load-time. This would be much faster than having the GUI rotate for you, and wouldn’t require the app’s knowledge. But of course this won’t work if the app needs direct access to the pixels.On Tue, Aug 06, 2002 at 01:28:19PM +0200, Lionel Ulmer wrote:

                        Lionel


Lionel Ulmer - http://www.bbrox.org/


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Only you can prevent creeping featurism!

I think since you want to rotate in 90? steps,
you don’t have to do real rotation.

So it’s easier, isn’t it.

I like the idea with the extra flag,
so the programmer can choose to use rotation or not.

Lion Vollnhals______________________________________________________________________________
WEB.DE MyPage - Ultimatives Kommunikationstool! Ihre Message sofort
online! Domain aenderbar! http://www.das.ist.aber.ne.lustige.sache.ms/

Maybe you should just implement a flag for “screen orientation aware”. This
way the graphics system knows to return a hardware surface or a software
surface. The software that isn’t coded to handle orientation will might
think it has a hardware surface but it really doesn’t, and rotation will be
handled for it. The blit/etc. routines will handle everything. Just like
with SDL_SetVideoMode you pass suggestions.

~Rob> ----- Original Message -----

From: Lion Vollnhals [mailto:schiggl@web.de]
Sent: Tuesday, August 06, 2002 5:21 AM
To: sdl at libsdl.org
Subject: Re: Re: [SDL] Hardware surfaces on handhelds

I think since you want to rotate in 90? steps,
you don’t have to do real rotation.

So it’s easier, isn’t it.

I like the idea with the extra flag,
so the programmer can choose to use rotation or not.

Lion Vollnhals


__
WEB.DE MyPage - Ultimatives Kommunikationstool! Ihre Message sofort
online! Domain aenderbar! http://www.das.ist.aber.ne.lustige.sache.ms/


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hmm… So if I’m understanding you right:

  • the app passes a flag to SDL_SetVideoMode indicating that it knows about rotation, along with the HWSURFACE flag
  • If the driver can provide a hardware surface but it’s rotated, it only gives a hardware surface if it sees that rotation flag from the app
  • the surface’s flags (or an extra member?) tell the app what rotation the surface has, if any

Sounds good to me.On Tue, Aug 06, 2002 at 09:54:55AM -0700, Robert Wohleb wrote:

Maybe you should just implement a flag for “screen orientation aware”. This
way the graphics system knows to return a hardware surface or a software
surface. The software that isn’t coded to handle orientation will might
think it has a hardware surface but it really doesn’t, and rotation will be
handled for it. The blit/etc. routines will handle everything. Just like
with SDL_SetVideoMode you pass suggestions.

~Rob

-----Original Message-----
From: Lion Vollnhals [mailto:schiggl at web.de]
Sent: Tuesday, August 06, 2002 5:21 AM
To: sdl at libsdl.org
Subject: Re: Re: [SDL] Hardware surfaces on handhelds

I think since you want to rotate in 90? steps,
you don’t have to do real rotation.

So it’s easier, isn’t it.

I like the idea with the extra flag,
so the programmer can choose to use rotation or not.

Lion Vollnhals


__
WEB.DE MyPage - Ultimatives Kommunikationstool! Ihre Message sofort
online! Domain aenderbar! http://www.das.ist.aber.ne.lustige.sache.ms/


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Only you can prevent creeping featurism!

Micah Dowty writes:

Hi,

I’ve been thinking about implementing support for hardware surfaces
in the PicoGUI driver for SDL. This might be useful also for the
Qtopia, Nano-X, and framebuffer drivers on handhelds.

The problem is, many handhelds (specifically the iPaq and Zaurus)
use a 320x240 LCD mounted in a portrait orientation, so that the
display has to be rotated in software to compensate. Most GUIs do
this automatically, but to give the application direct access to the
framebuffer the app has to be aware of the rotation.

I’d like to be able to have rotation-aware applications access the
framebuffer directly on handhelds like this while non-rotation-aware
apps go through the GUIs rotation layer. How should this be
implemented in SDL? Maybe a flag to SDL_SetVideoMode?

Note on Qtopia: The SDL code already does access the framebuffer
memory directly when blitting. It has incomplete device support in
terms of rotation and such however.

That said, it’s always blitted through a software allocated surface
(the one SDL_UpdateRects / SDL_Flip blits from). Giving direct access
to the client to the underlaying display memory is probably neither
desirable or needed. Why? Well:

  • You never want to build your scene directly onto the display. This
    will cause flickering.
  • If you allow direct access, the user would therefor manually have to
    do double buffering and rotation. This makes no sense since the
    performance would be identical.

Thing is, there is no way afaik to allow double buffered hardware
surfaces (meaning the “shadow” surface is also using display memory
and a SDL_Flip simply moves the “pointer” for the display to another
location in the memory).

So to sum it up, on the Zaurus or other Qtopia devices, you will
always need to use an intermediate surface to do blitting on. Why not
let SDL handle this rather than letting the user do it?–
[ Below is a random fortune, which is unrelated to the above message. ]
Better to light one candle than to curse the darkness.
– motto of the Christopher Society

Micah Dowty writes:

Hmm… So if I’m understanding you right:

  • the app passes a flag to SDL_SetVideoMode indicating that it knows about rotation, along with the HWSURFACE flag
  • If the driver can provide a hardware surface but it’s rotated, it only gives a hardware surface if it sees that rotation flag from the app
  • the surface’s flags (or an extra member?) tell the app what rotation the surface has, if any

So now please tell me what the benefit is here? That the SDL app could
pre-rotate surfaces and do all logic based on the rotation, for a
small speed benefit? Since you need to double buffer in either case
(currently it’s done automagically), the benefit in time for a
SDL_Flip or fullscreen update would be in the range of 2-3 ms.

Also note that there would have to be a way for SDL to tell the
application WHAT the rotation is of the framebuffer, or you would need
platform specific code to figure that out.

I simply think the small benefit in speed probably isn’t worth it
considering the cost (in times of application coding etc) of this
small benefit.–
[ Below is a random fortune, which is unrelated to the above message. ]
What fools these morals be!

SDL’s blitters don’t support it, but it is possible to blit from
multiple surfaces onto a seperate dest surface… In this case there is
no need for a back-buffering, as the result is potentially the final
result…This would require custom blitters, but could be done…

-LorenOn Tue, 2002-10-01 at 16:38, David Hedbor wrote:

That said, it’s always blitted through a software allocated surface
(the one SDL_UpdateRects / SDL_Flip blits from). Giving direct access
to the client to the underlaying display memory is probably neither
desirable or needed. Why? Well:

  • You never want to build your scene directly onto the display. This
    will cause flickering.
  • If you allow direct access, the user would therefor manually have to
    do double buffering and rotation. This makes no sense since the
    performance would be identical.