>> Last time I tried my hands on the SavageFB (DirectFB 0.9.14) I found >> that the SavageFB driver is WAAAY slower than VESA FB. Especially if >> you're using any alpha/transparency. The system I tried it on was a >> 1.2Ghz Celeron with VIA Twister (which is a Savage4 or something) >> running the latest 2.4.x at the time. >> >> I don't care much for the feature of changing resolutions on the fly, >> so VESA FB works fine, but I still find it odd that it would be faster >> than the "native" driver.
> if you use savagefb, directfb uses its accelerated savage driver. > window contents are normally stored in video memory, if the driver > supports blitting. > if you make a window transparent, it cant be blitted by the savage > driver because blending is not supported by the driver. so a software > fallback will occur. > this software fallback is extremely slow because reading from the video > memory is MUCH slower than from system memory. This is so odd, one would think it would be faster :) > DirectFB has also some switches like > I bet if you use savagefb and --dfb:no-hardware, your programs will run > as fast as with vesafb. Nope, still a bit slower. Dunno why, but it was (or maybe I was a bit jaded when I tried) > the best solution would be blending support in directfb's savage driver. Indeed... And my guess is that if I ask about it, the reply is "Feel free to do it yourself" ;) Honestly, is anyone working on this? There must be truckloads of Savage based system out there that could use this? > since this is a frequently asked question we should move it to some FAQ. True... or atleast place it in the Modules section as with the other drivers (ATI) A last thought, couldn't one write some sort of abstractionlayer that would make it possible to use the binary drivers for X in DirectFB? (Nope, never done drivers and hardware stuff, thats why I'm asking :) ) /Henric -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
