[pygame] Pygame support for both SDL and DirectFB

[Dmitry Borisov]

Guys,
Just trying to understand the need of the above.
I was pretty bored when trying SDL to use all features of my CLE266 chipset through using DirectFB. In some cases it works 8 times slower, in some it does not work at all.
I was trying to fix that miscommunication in SDL but realized that it would be very messy to use DirectFB from python through pygame->SDL->DFB. Very long run isn't it ?
My next guess was to use pydfb to get that thing working. But it has very weird and raw interface, so I can hardly do something serious with it.
So I came up to the need for pygame to support DirectFB. The major reason for that is performance. SDL->DirectFB giving me 10-12 MPix/sec ( 7-8 MPix/sec with pygame+psyco ) whereas the same DirectFB app can easily run up to 80 MPix/sec.
My questions would be:
Is it really mean to someone to have pygame using DirectFB as a displaying layer ?
Don't you think it would be too bad to have pygame->DFB on linux only ( meaning no portability in this case ) ?

Any comments ? Thoughts ?
Thanks,
Dmitry/

[Bob Ippolito]

Post by Dmitry Borisov
Just trying to understand the need of the above.
I was pretty bored when trying SDL to use all features of my CLE266
chipset through using DirectFB. In some cases it works 8 times slower,
in some it does not work at all.
I was trying to fix that miscommunication in SDL but realized that it
would be very messy to use DirectFB from python through
pygame->SDL->DFB. Very long run isn't it ?
My next guess was to use pydfb to get that thing working. But it has
very weird and raw interface, so I can hardly do something serious
with it.
So I came up to the need for pygame to support DirectFB. The major
reason for that is performance. SDL->DirectFB giving me 10-12 MPix/sec
( 7-8 MPix/sec with pygame+psyco ) whereas the same DirectFB app can
easily run up to 80 MPix/sec.
Is it really mean to someone to have pygame using DirectFB as a displaying layer ?
Don't you think it would be too bad to have pygame->DFB on linux
only ( meaning no portability in this case ) ?

This sounds more like a SDL problem than a pygame problem doesn't it?

Besides, In my opinion, pygame is probably too low level to support
multiple backends. If you're going to go through all the trouble of
abstracting all these graphics issues then you should probably do it at
the sprite level or something.

-bob

[Pete Shinners]

Post by Dmitry Borisov
pygame->SDL->DFB. Very long run isn't it ?
My next guess was to use pydfb to get that thing working. But it has
very weird and raw interface, so I can hardly do something serious
with it.

i doubt the pyfb interface will be any faster than the pygame through sdl
way. although it may directly expose more hardware accelerated draw
operations, which sdl does not have much of. the difference between 10
Mpix/s and 80Mpix/s is not because of a middle library translating function
calls. It definitely means you don't have SDL keeping its Surfaces in a
format directly blittable by directfb.

i'm sure the reason you are seeing directfb code faster is because it's
images are in a native blittable format. you can do that with SDL/Pygame by
passing the HWSURFACE to the display.set_mode() call.

bob is exactly right about adding multiple backends into pygame. it really
needs to be higher level, handling more of the details for you. it would
probably not be hard to make a python wrapper for pyfb that looked similar
to pygame for what you need.