[directfb-users] How does rotation (90/270 degrees) work?

[Karim 'Kasi Mir' Senoucci]

Hello everyone,
I don't know if anybody's reading these lists anymore (my last question
didn't get any replies whatsoever), but I'll try it once more:

I see the nice example of a sideways window on directfb.org
(Loading Image...), and I
wouldn't even need something that complicated: I want to turn the whole
display (because the monitor is used in portrait orientation) by 90 or
270 degrees, so that I get a 1080x1920 display instead of a 1920x1080 one.

I use dfb++, but those are only wrappers for the directfb calls, so that
shouldn't be the problem, I think.

At the moment, I pass "layer-rotate:90" via argc/argv which seems to be

(!!!) *** UNIMPLEMENTED [dfb_surface_create] *** [surface.c:179]
(!!!) *** UNIMPLEMENTED [dfb_surface_reconfig] *** [surface.c:525]

and the display remains in landscape orientation. As far as I can see
from the DirectFB sources (surface.c), rotation is indeed unimplemented
in the surfaces.

DirectFB::Init (&argc, &argv);
dfb=DirectFB::Create();
dsc.flags = DSDESC_CAPS;
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_PRIMARY);
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_SYSTEMONLY);
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_DOUBLE);
DFB_ADD_SURFACE_DESC(dsc.flags, DSDESC_PIXELFORMAT);
dsc.pixelformat= DSPF_RGB32;

6. I create that surface:

primary=dfb->CreateSurface(dsc);

All my DrawString(), SetColor(), FillRectangle() etc. operations to fill
the display with the intended information are done in regard to this
primary surface, or they are made on other surfaces I create and then
Blit() to the primary surface. I don't use any window objects as I don't
have a window layout on screen, but just one full-screen display.

What am I doing wrong? Can anyone give me any pointers how to get the
rotation I want to see? 180 degrees works fine, just 90 and 270 don't do
anything.

prim_layer=dfb->GetDisplayLayer(DLID_PRIMARY);
prim_layer->SetRotation(180);
IDirectFBDisplayLayer::SetRotation(int) -> Access denied!

So that doesn't work either? Is there another way that I just fail to see?



I'm currently using DirectFB 1.4.17 with DFB++ 1.2.0 running on an Intel
Atom Board using kernel 3.4.9 with modesetting enabled. This is my debug

~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.17 |~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2001-2012 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
----------------------------------------------------------------
(*) DirectFB/Core: Single Application Core. (2012-08-22 17:53) [ DEBUG
][ TRACE ]
(*) Direct/Thread: Started 'VT Switcher' (10410) [CRITICAL OTHER/OTHER
0/0] <8388608>...
(*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at
0xd0030000, 8100k (MMIO 0x00000000, 0k)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Microsoft Microsoft Notebook Op (1) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: HID Keyboard Device (2) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: HID Keyboard Device (3) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Sleep Button (4) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Power Button (5) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT
OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver
(*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER
0/0] <8388608>...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: IMPS/2 Mouse (1) 1.0 (directfb.org)
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: IMPS/2 Mouse (2) 1.0 (directfb.org)
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(!!!) *** UNIMPLEMENTED [dfb_surface_create] *** [surface.c:179]
(!!!) *** UNIMPLEMENTED [dfb_surface_reconfig] *** [surface.c:525]

If you need any further information, just ask. I'm grateful for any help
on the subject, as I'm starting to go nuts here. :-)

Greetings
Kasi Mir

[Chuck McManis]

Presumably you recognized your bug where you said '180' but you really
meant '90' (rotating 180 will cause the display to be upside down).

I built DirectFB from the git repo (v1.7) and didn't have the same issues.
Mostly I've been trying to get to an accellerated solution but it seemed to
work as I would expect. I'm also running on ARM rather than x86 but that
shouldn't matter. Do you have a buildable piece of sample code that doesn't
work?

--Chuck

On Wed, Aug 22, 2012 at 12:04 PM, Karim 'Kasi Mir' Senoucci <

Post by Karim 'Kasi Mir' Senoucci
Hello everyone,
I don't know if anybody's reading these lists anymore (my last question
I see the nice example of a sideways window on directfb.org (
Loading Image...>),
and I wouldn't even need something that complicated: I want to turn the
whole display (because the monitor is used in portrait orientation) by 90
or 270 degrees, so that I get a 1080x1920 display instead of a 1920x1080
one.
I use dfb++, but those are only wrappers for the directfb calls, so that
shouldn't be the problem, I think.
At the moment, I pass "layer-rotate:90" via argc/argv which seems to be
(!!!) *** UNIMPLEMENTED [dfb_surface_create] *** [surface.c:179]

(!!!) *** UNIMPLEMENTED [dfb_surface_reconfig] *** [surface.c:525]

and the display remains in landscape orientation. As far as I can see from
the DirectFB sources (surface.c), rotation is indeed unimplemented in the
surfaces.
DirectFB::Init (&argc, &argv);
dfb=DirectFB::Create();
dsc.flags = DSDESC_CAPS;

DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_PRIMARY);
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_SYSTEMONLY);
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_DOUBLE);
DFB_ADD_SURFACE_DESC(dsc.**flags, DSDESC_PIXELFORMAT);
dsc.pixelformat= DSPF_RGB32;

primary=dfb->CreateSurface(**dsc);
All my DrawString(), SetColor(), FillRectangle() etc. operations to fill
the display with the intended information are done in regard to this
primary surface, or they are made on other surfaces I create and then
Blit() to the primary surface. I don't use any window objects as I don't
have a window layout on screen, but just one full-screen display.
What am I doing wrong? Can anyone give me any pointers how to get the
rotation I want to see? 180 degrees works fine, just 90 and 270 don't do
anything.
prim_layer=dfb->**GetDisplayLayer(DLID_PRIMARY);
prim_layer->SetRotation(180);
IDirectFBDisplayLayer::**SetRotation(int) -> Access denied!
So that doesn't work either? Is there another way that I just fail to see?
I'm currently using DirectFB 1.4.17 with DFB++ 1.2.0 running on an Intel
Atom Board using kernel 3.4.9 with modesetting enabled. This is my debug
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.17 |~~~~~~~~~~~~~~~~~~~~~~~~~~

(c) 2001-2012 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
------------------------------**------------------------------**----
(*) DirectFB/Core: Single Application Core. (2012-08-22 17:53) [ DEBUG ][
TRACE ]
(*) Direct/Thread: Started 'VT Switcher' (10410) [CRITICAL OTHER/OTHER
0/0] <8388608>...
(*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at
0xd0030000, 8100k (MMIO 0x00000000, 0k)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Microsoft Microsoft Notebook Op (1) 0.1 (directfb.org
)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: HID Keyboard Device (2) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: HID Keyboard Device (3) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Sleep Button (4) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Power Button (5) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT
OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver
(*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: IMPS/2 Mouse (1) 1.0 (directfb.org)
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: IMPS/2 Mouse (2) 1.0 (directfb.org)
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(!!!) *** UNIMPLEMENTED [dfb_surface_create] *** [surface.c:179]
(!!!) *** UNIMPLEMENTED [dfb_surface_reconfig] *** [surface.c:525]

If you need any further information, just ask. I'm grateful for any help
on the subject, as I'm starting to go nuts here. :-)
Greetings
Kasi Mir
______________________________**_________________
directfb-users mailing list
http://mail.directfb.org/cgi-**bin/mailman/listinfo/directfb-**users<http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users>

[Karim 'Kasi Mir' Senoucci]

Hello all,
I'm still unable to get DirectFB to rotate by 90 or 270 degrees for a
display in portrait orientation; the program just ignores the parameter
and displays in zero degrees.

As Chuck McManis suggested, I now wrote a small test program to
illustrate the problem. The programm vid-test opens a full-screen view
and draws one rectangle, then waits for any keyboard input to quit.

I compiled this using the git version of DirectFB with the following

vid-test: vid-test.o
g++ -o vid-test -lidn -lpthread -ldirectfb -ldfb++ vid-test.o
vid-test.o: vid-test.cpp
g++ -I /usr/include/directfb/ -I /usr/include/dfb++/ -c
vid-test.cpp
vid-test --dfb:layer-rotate=<x>,mode=1920x1080,depth=32,pixelformat=RGB32

where <x> is replaced by 0, 90, 180, or 270. 0 and 180 work as expected,
90 and 270 don't.

I'm banging my head against the wall here, expecially since the DirectFB
website suggests rotation has been working in DirectFB *for three
years*. Can anybody tell me what exactly I am doing wrong, and more
importantly, how to fix it? Otherwise, my only alternative would be
rewriting the whole 10000-line program using another display library
that really provides portrait mode and not just claims to do so (if
there even is such a thing).

Program follows:
------------------------------------------------------------------------------------------------------------------------------------------------------
#define _REENTRANT
#define __USE_BSD
#include <memory>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/signal.h>
#include <sys/stat.h>
#include <sys/param.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <stdlib.h>
#include <stdlib.h>
#include <string.h>
#include <dfb++.h>


static IDirectFB *dfb = NULL;
static IDirectFBSurface *primary = NULL;

bool RunMe;

static IDirectFBInputDevice *keyboard = NULL;
static IDirectFBEventBuffer *keyboard_buffer = NULL;
DFBInputEvent keyboard_event;
DFBSurfaceDescription dsc;
IDirectFBDisplayLayer *prim_layer;
IDirectFBSurface *base_surface;


int main (int argc, char **argv)
{
printf("**********************************************************************\n");

try
{
printf("Calling dfb:Init...\n");
DirectFB::Init (&argc, &argv);
printf("Calling dfb:Create...\n");
dfb=DirectFB::Create();

printf("Calling dfb:GetDisplayLayer...\n");
prim_layer=dfb->GetDisplayLayer(DLID_PRIMARY);
if (prim_layer==NULL)
printf("Couldn't get primary layer\n");
printf("Calling dfb:SetCoopLevel...\n");
dfb->SetCooperativeLevel(DFSCL_EXCLUSIVE);
printf("Calling dfb:GetSurface...\n");
base_surface=prim_layer->GetSurface();
if (base_surface==NULL)
printf("Couldn't get base surface\n");

printf("Setting dfb:GetInputDevice...\n");
keyboard=dfb->GetInputDevice(DIDID_KEYBOARD);
if (keyboard!=NULL)
keyboard_buffer=keyboard->CreateEventBuffer();
else
printf("Keyboard input device not found...\n");

dsc.flags = DSDESC_CAPS;
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_PRIMARY);
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_SYSTEMONLY);
// DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_VIDEOONLY);
DFB_ADD_SURFACE_CAPS( dsc.caps, DSCAPS_DOUBLE);
DFB_ADD_SURFACE_DESC(dsc.flags, DSDESC_PIXELFORMAT);
dsc.pixelformat= DSPF_RGB32;

printf("Create primary surface...\n");
primary=dfb->CreateSurface(dsc);

primary->SetColor(0xff,0xff,0xff);
primary->DrawRectangle(100,100,400,200);

RunMe=true;
while(RunMe==true)
{
while (keyboard_buffer->HasEvent())
{
keyboard_buffer->GetEvent(DFB_EVENT(&keyboard_event));
if (keyboard_event.type==DIET_KEYPRESS)
{
RunMe=false;
};
};
primary->Flip(NULL, DSFLIP_WAITFORSYNC);
};
}
catch (DFBException *ex)
{
std::cerr << std::endl;
std::cerr << "Caught exception!" << std::endl;
std::cerr << " -- " << ex << std::endl;
RunMe=false;
};

printf("Releasing input devices...\n");
keyboard->Release();
printf("Releasing surfaces...\n");
primary->Release();
printf("Releasing DirectFB...\n");
dfb->Release();
printf("Quitting...\n");
exit(EXIT_SUCCESS);
printf("**********************************************************************\n");
}

------------------------------------------------------------------------------------------------------------------------------------------------------


Any help appreciated
Kasi Mir

[Karim 'Kasi Mir' Senoucci]

Hi,

Have you grepped into the code to see what happens when the
layer-rotate=<x> option is passed?

Into the code of DirectFB itself? No, I haven't done that so far. As I
have no knowledge of the DirectFB sources whatsoever, this would
probably take many, many hours, which is why I tried asking those with
said knowledge first who can tell me whether I'm doing anything wrong
right away. As it seems, it's not that simple. :-)

Unfortunately, I can't find any documentation on directfb.org or
elsewhere which tells me what is needed for layer-rotate to work, which

Are you using a DirectFB system module that do actually support such a
configuration option?

Short answer: I have no idea (though my guess at the moment would be no,
as it obviously doesn't work). I can't find any documentation from which
I can deduct the answer to your question, which again is my reason for
asking here.

Actually, I'm not even sure what you mean by "DirectFB system module" -
a hardware-specific rendering module within DirectFB, the actual frame
butter driver, or something else entirely.

Let's start from the other direction - I tell you what I'm using:

I'm running my software on a variety of Mini-ITX boards:

* VIA EPIA 6000ML (VIA C7 CPU)
* VIA EPIA 10000ML ( " )
* Intel D945 (Intel Atom 1st generation)
* Intel D410 (Intel Atom 2nd generation)
* Intel D425 (Intel Atom 3rd generation)
* Intel D2700 (Intel Atom 4th generation)

On the via boards, I'm using the viafb frame buffer kernel driver, on
the D945, I'm using intelfb. For the D410 and D425, as there is no
hardware-specific kernel driver, I use uvesafb. Finally, the D2700
supports the newer kernel-modesetting and DRI, so I use the inteldrmfb
driver.

Of those frame buffers, as far as I could find out, DirectFB has
specific drivers only for the VIA boards (UniChrome), for all others,
the "MMX Software Rasterizer" is used. As I have no videos or animations
to display, this is fine by me. My program opens a primary, full-screen
surface onto which everything is painted via DrawRectangle(),
DrawString(), Blit() etc. directly. There are no windows, everything is
a fixed full-screen layout.

By the way: if there is another way to rotate the display (i.e.
everything that is displayed on screen) by 90 or 270 degrees, I'll
happily give it a try. I don't have to use the "layer-rotate"
command-line parameter, it's just the only thing I could find that at
least is documented.

I hope the above info helps in getting closer to a solution. If any
additional information is necessary, feel free to ask. Thank you very
much in advance for your efforts.

Greetings
Kasi Mir

[Karim 'Kasi Mir' Senoucci]

Hi,

Hi Karim,
On Wed, Sep 12, 2012 at 7:36 PM, Karim 'Kasi Mir' Senoucci

Hi,
Have you grepped into the code to see what happens when the
layer-rotate=<x> option is passed?
Into the code of DirectFB itself? No, I haven't done that so far. As I have
no knowledge of the DirectFB sources whatsoever, this would probably take
many, many hours, which is why I tried asking those with said knowledge
first who can tell me whether I'm doing anything wrong right away. As it
seems, it's not that simple. :-)

code is usually the ultimate documentation.

Yes, but it's usually also the worst kind of documentation, depending on
how well it is documented. Glancing into the DirectFB source, I don't
see many comments, which means that without external knowledge of some
kind about the general structure of things, it's quite a arduous (and
time-consuming) task to get started understanding anything in those cases.

The DirectFB system module is what interfaces with the framebuffer
driver, such as what you listed here viafb, vesafb and inteldrmfb.
DirectFB would be using fbdev system module to talk to those.

Okay, so the fbdev system module must support layer-rotate, which is
parsed in conf.c and then written into an internal structure or class,
as far as I understand it. Unfortunatly, I couldn't grep any use of the
structure memeber in the whole system subdirectory, not just not in the
fbdev system module. As I said, whitout knowing anything about the
internal architechture of DirectFB, it's hard to follow the flow of
information through the mostly undocumented source files.

By the way: if there is another way to rotate the display (i.e. everything
that is displayed on screen) by 90 or 270 degrees, I'll happily give it a
try. I don't have to use the "layer-rotate" command-line parameter, it's
just the only thing I could find that at least is documented.
Yes. You could use (you UI and rendering code) IDirectFBWindow(s) and
rotate these 90°, 180° and 270°.

Thanks for the suggestion; I have written a small test program in
DirectFB (without DFB++) which first creates a window as big as the
whole display and then makes all the DrawStrings() onto the window
surface instead of the primary one. That really works for the most part;
unfortunateley, the DFB++ bindings I use in my program (which I started
programming seven years ago when those bindings were fresh) haven't been
updated in ages, so the SetRotation method is unknown for windows.

surface->DrawRectangle(surface,200,50,300,60);
layer->CreateWindow( layer, &dsc, &window );
window->GetSurface( window, &surface );
surface->Clear( surface, 0,0,0, 0xff );
surface->SetColor(surface, 0x00,0x80,0x80,0xff);
surface->DrawRectangle(surface,200,50,300,60);
surface->SetFont(surface,font);
surface->DrawString(surface,"Test",-1,99,79,DSTF_LEFT);

To doing the same thing in my DFB++ test program which I posted here two

prim_window = prim_layer->CreateWindow(dsc);
primary=prim_window->GetSurface();
primary->Clear(0,0,0,0xff);
primary->SetColor(0x00,0x80,0x80,0xff);
primary->DrawRectangle(200,50,300,60);
primary->SetFont(font);
primary->DrawString("Test",-1,99,79,DSTF_LEFT);

just produces a black screen with a mouse pointer. I'm still kind of
hesitating ditching DFB++ altogether because of my roughly 800
DFB++-based calls in the program which I'd have to rewrite; but as
unless I can the above working, I fail to see another way.

The second problem is the mouse pointer. Up until now, I got rid of that
one by calling SetCooperativeLevel(DLSCL_EXCLUSIVE) on the primary
layer. But I can't use DLSCL_EXCLUSIVE when I create windows, so that
option is gone. Is there any way to use an DirectFB window but still
hide the mouse cursor?

If you have an acceleration module that's able to handle rotation,
then the composition will be h/w accelerated.

At least without the additional window, the program was fast enough
using the software rasterizer; furthermore, there aren't any
acceleration modules for Intel GMA3150, GMA36x0, or GMS950, anyway
(AFAICS).

Greetings
Kasi Mir

[Ezequiel Garcia]

Karim,

On Wed, Sep 12, 2012 at 2:00 PM, Karim 'Kasi Mir' Senoucci

Post by Karim 'Kasi Mir' Senoucci
I'm banging my head against the wall here, expecially since the DirectFB

Don't do that: walls are usually tougher than heads, and ideas won't come
up easier on a smashed head ;-)

Post by Karim 'Kasi Mir' Senoucci
website suggests rotation has been working in DirectFB for three years. Can
anybody tell me what exactly I am doing wrong, and more importantly, how to
fix it? Otherwise, my only alternative would be rewriting the whole
10000-line program using another display library that really provides

(Perhaps you've already answer this but...) do you need to rotate on a
fast-path?
Meaning... do you need to rotate N times per second.

I'm asking you this because I remember that in the past I've managed
to implement
software-rotation to run on 25 fps.
Have yo tried to do this? Have you measured performance?

I could be wrong, but I don't think it's something difficult.

Hope this helps,
Ezequiel.

[Karim 'Kasi Mir' Senoucci]

Hi,

Post by Ezequiel Garcia
Karim,
On Wed, Sep 12, 2012 at 2:00 PM, Karim 'Kasi Mir' Senoucci

Post by Karim 'Kasi Mir' Senoucci
I'm banging my head against the wall here, expecially since the DirectFB

Don't do that: walls are usually tougher than heads, and ideas won't come
up easier on a smashed head ;-)

No worries, it's all just drywall. :-)

Post by Ezequiel Garcia
(Perhaps you've already answer this but...) do you need to rotate on a
fast-path?
Meaning... do you need to rotate N times per second.

No, not at all. In fact, this will be a configuration option in my
program which then remains unchanged for the whole running time.

Post by Ezequiel Garcia
I'm asking you this because I remember that in the past I've managed
to implement
software-rotation to run on 25 fps.
Have yo tried to do this? Have you measured performance?

My program currently doesn't refresh the display more than eight times
per second, so there really is no need for more fps. :-)

Greetings
Kasi Mir

[Ezequiel Garcia]

Hi,

On Thu, Sep 13, 2012 at 11:05 AM, Karim 'Kasi Mir' Senoucci

Post by Karim 'Kasi Mir' Senoucci
Hi,

Post by Ezequiel Garcia
Karim,
On Wed, Sep 12, 2012 at 2:00 PM, Karim 'Kasi Mir' Senoucci

Post by Karim 'Kasi Mir' Senoucci
I'm banging my head against the wall here, expecially since the DirectFB

Don't do that: walls are usually tougher than heads, and ideas won't come
up easier on a smashed head ;-)

No worries, it's all just drywall. :-)

Post by Ezequiel Garcia
(Perhaps you've already answer this but...) do you need to rotate on a
fast-path?
Meaning... do you need to rotate N times per second.

No, not at all. In fact, this will be a configuration option in my program
which then remains unchanged for the whole running time.

Post by Ezequiel Garcia
I'm asking you this because I remember that in the past I've managed
to implement
software-rotation to run on 25 fps.
Have yo tried to do this? Have you measured performance?

My program currently doesn't refresh the display more than eight times per
second, so there really is no need for more fps. :-)

In that case, why don't you rotate "by-hand"?

[Karim 'Kasi Mir' Senoucci]

Hi,

Post by Ezequiel Garcia

Post by Karim 'Kasi Mir' Senoucci
My program currently doesn't refresh the display more than eight times per
second, so there really is no need for more fps. :-)

In that case, why don't you rotate "by-hand"?

What do you mean by this? Are you suggesting that I should "simply"
rotate every of my roughly 800 calls to DirectFB instead of rotating
just the surface (or layer) once?

Greetings
Kasi Mir

[Ezequiel Garcia]

Hi,

On Thu, Sep 13, 2012 at 12:39 PM, Karim 'Kasi Mir' Senoucci

Hi,

Post by Ezequiel Garcia

Post by Karim 'Kasi Mir' Senoucci
My program currently doesn't refresh the display more than eight times per
second, so there really is no need for more fps. :-)

In that case, why don't you rotate "by-hand"?

What do you mean by this? Are you suggesting that I should "simply" rotate
every of my roughly 800 calls to DirectFB instead of rotating just the
surface (or layer) once?

Well, I'm not familiar with your app. But, I would think to be wise to have
just one call to Flip(). You simply have to rotate before flipping.

Of course, I might be wrong. But, do you have 800 different places
where you call Flip()?

[Karim 'Kasi Mir' Senoucci]

Hi,

Post by Ezequiel Garcia

What do you mean by this? Are you suggesting that I should "simply" rotate
every of my roughly 800 calls to DirectFB instead of rotating just the
surface (or layer) once?

Well, I'm not familiar with your app. But, I would think to be wise to have
just one call to Flip(). You simply have to rotate before flipping.

Rotate what, exactly, and with which call?

Post by Ezequiel Garcia
Of course, I might be wrong. But, do you have 800 different places
where you call Flip()?

No, I said calls to DirectFB, not calls to Flip(), that one I have just
once. But how do I "rotate" the surface I am about to flip? I know how
to set rotation on a layer (in theory, as it doesn't work in practice)
and a window, but for a surface, I'm at a loss.

Please note that DSCAPS_ROTATED is documented as "(unimplemented!)" in
the DirectFB reference manual on directfb.org.

Greetings
Kasi Mir

[Ezequiel Garcia]

This post might be inappropriate. Click to display it.